27 ms·

Google's “Director of Engineering” Hiring Test (2016)

569 points by josephscott 8y ago

wyldfire 8y ago
> Me: on which kind of CPU? Why not let me compare my code to yours in a benchmark? While I agree that this is the right answer, questions regarding "Big-O" are trying to find out whether or not you can evaluate the complexity of an algorithm. If you can, you have some hope of writing different useful benchmarks that could be compared, where sometimes you can see orders of magnitude of improvement. If you can't, you might be just blindly tweaking the code to get 1-5% improvement from compiler flags, assembly optimizations, etc. In practice this recruiter might be bad at their job by binding themselves so rigidly to the script.
- jerf 8y ago
  "While I agree that this is the right answer, questions regarding "Big-O" are trying to find out whether or not you can evaluate the complexity of an algorithm." Most algorithms for counting bits will be O(1) for a given int, so O(number of ints) for a list of ints. Algorithms that aren't O(1) for a given int [1] will still be essentially O(1) since the upper bound would be so tight. So I don't think that was a Big-O question. [1]: "count = 0; while i != 0 { count += i % 2; i >> 2 }". Technically this is O(leftmost set bit), but on a fixed-bit int could be considered O(1) with a suitable constant. Note that algorithm isn't entirely pointless; it works on bigints too, so in something like Python where ints and bigints are not distinguished by type you could use it as a fallback for "generic int" (which may include user-defined classes). (Though of course there are ways to speed it up.)
- SilasX 8y ago
  Well, I've been in this scenario before, and have resorted to that. I was this guy [1]. (Interview question in link, I had written a solution.) The interviewer stubbornly insisted that the run time was n^2 because it had an inner loop. (Never mind that the inner wasn't looping over pairs with the bigger loop, but just the bits within that element.) I went through a number of heuristics to convince him otherwise: what if you doubled the list, how would that analytically affect the run time? What if the elements were bigger? (as you can find from the reddit thread) Disturbingly, I asked him what he would need to see to convince him that the code I wrote was O(n), and he said, "no inner loop", which reveals a profound misunderstanding of both the issue at hand, and how to resolve disagreement. At that point, I resorted to saying, well, let's run the code with increasing input size and see how it scales (which would give valuable information about its actual scaling behavior). Then he refused, left the room, and told the director to veto me from the rest of that day's interviews. [1] https://news.ycombinator.com/item?id=6070001 https://news.ycombinator.com/item?id=6070001
  - wyldfire 8y ago
    > Then he refused, left the room, and told the director to veto me from the rest of that day's interviews. "Bullet dodged" -- he did you a huge favor.
ebikelaw 8y ago
Whatever you are about to say was likely covered in the existing 1000-comment thread https://news.ycombinator.com/item?id=12701272 https://news.ycombinator.com/item?id=12701272
jschwartzi 8y ago
I would have hung up about halfway in when the recruiter said there was a best sorting algorithm. That is patently false, and the best algorithm depends heavily on your needs at the time which is where engineering comes in. Whoever wrote that test didn't seem to understand what engineers do, but what makes a competent engineering organization.
outside2344 8y ago
What that list should really have in it is: 1) A female employee complains of harassment: what do you do? 2) What is an effective devops approach for an Android app? 3) How do you build a culture of teamwork across teams versus a zero sum culture.
pinewurst 8y ago
Another data point - I had a very similar Google recruiter "test", being disdainfully dismissed because I couldn't/wouldn't regurgitate the same incorrect template answers they had. I've since terminated any approaches by Google recruiters as being a waste of my time and emotional energy.
- ThePadawan 8y ago
  I'm in a similar boat - I've been approached twice in the past, and both times went on to the onsite interview day only to be told "We are unsure whether we want to hire you, so we will err on the side of caution and ask you to come back in a year". However, I am still getting contacted randomly by their recruiters without any indication why I should invest energy to try again - the result will generally the same. Getting an answer to that question also turned out to be impossible, since I only got stock answers back. Really shameful for a company which (at least in my perception) prides itself on celebrating an engineer-driven culture (instead of one driven by HR).
- logicallee 8y ago
  This is similar to taking standardized tests where you are smarter than the question-writer. What would you select as the answer to the following question: " x is an integer. If x² = 16, then x =? A. 1. B. 2. C. 4. D. 16. E. Not enough information. " Think hard and tell me what you would select. For me it is VERY clear that I have to select C, 4. It is just as clear that it is the wrong answer, and the correct answer is E, because x can be -4 or 4, and you do not have enough information. How do I know to select C? Mostly, from the context. "x is an integer" is a weird and stupid way to begin a question like that, the whole question is pretty stupid. The choices are just natural whole numbers, and ones that someone might select. Still, the question has a VERY clear correct answer, which is E. It is not the answer you should select. Likewise if you are being given a technical interview by someone reading stupid template questions, then you need to figure out how dumb the template is, and answer on that level. It's not about being correct. The question "standardized test" I just made up and answered should be answered incorrectly. Don't answer questions like that correctly.
  - 8y ago
koolba 8y ago
This is so good I can’t tell if it’s literal or a parody. The part about inodes in particular.
- pinewurst 8y ago
  I was asked to regurgitate Linux header file constants. I believe Google is attempting to push the boundaries of self-parody as they push computer science.
- geofft 8y ago
  The interviewee's answer to the inode thing is simply wrong. An inode is metadata (or "attributes", sure): it's not an index or an identifier. I think the interviewee is thinking of the inode number, which is a related but different thing. The interviewer was right.
  - psyc 8y ago
    http://www.linfo.org/inode.html http://www.linfo.org/inode.html I swear this is about the 20th time in a week I've seen a good comment (the parent) in the gray. Unless I'm imagining things, this has been happening with extremely noticeable increasing frequency. I've held off saying anything about it for days while it keeps happening more and more.
draw_down 8y ago
I’m not sure I could take more than a couple of those extremely petty replies from the interviewer before I would just tap out. Why even bother having this interview conducted by a human when they display as much nuance and understanding as a Scantron? “Quicksort is the best sort, period.” Fuck off.
eitally 8y ago
> Recruiter: that's not the answer I have on my sheet of paper. This is the problem. Google hires as such ridiculous volume (onboarding >5000 people last quarter, and on average growing at ~10000 employees (FTEs) per year) that the process gets abstracted into whatever Google thinks can be done algorithmically. This makes almost no sense for most roles, including any type of specialist as well as middle/senior management, and you end up with situations like you faced. If it makes you feel better, it's equally frustrating for hiring managers, who just get input from recruiters that so-and-so failed the phone screen. I'm at the point where I tell my recruiters to let me do the phone screens myself whenever they come across what -- on paper -- looks like a strong, viable candidate. <banghead>
- itissid 8y ago
  Reminds me of the time a TSA person at the airport asked a programmer at the port of entry to answer some canned CS questions from wikipedia and expected the exact answers...
  - cordite 8y ago
    Could you find the source for this?
    - lxhrstn 8y ago
      https://twitter.com/cyberomin/status/835888786462625792 https://twitter.com/cyberomin/status/835888786462625792
    - KboPAacDA3 8y ago
      https://www.wired.com/2017/03/immigrant-says-customs-quizzed-prove-can-code/ https://www.wired.com/2017/03/immigrant-says-customs-quizzed...
    - cabotmoose 8y ago
      Believe it might be this: https://www.wired.com/2017/03/immigrant-says-customs-quizzed-prove-can-code/ https://www.wired.com/2017/03/immigrant-says-customs-quizzed...
andrew_ 8y ago
Tossing my hat in the ring with a similar experience. Was approached in 2003 because of an app I had written that got attention, and was told that Googlers wanted to speak with me about the app. What followed was three calls with gate-keepers of sorts, between which there was zero knowledge transfer from call to call. None of them inquired about the app and all of them asked questions so unrelated to the app that they might as well have been interviewing me for a position writing Sanskrit. On the last of the 3 calls I asked the interviewer when someone was going to inquire about the app, to which the person replied that they had no idea what it was and that they were told I had applied for a position. Though they couldn't tell me what that position apparently was. I kindly requested they not contact me again. I'm no all-star, I don't think I'm special, and I was still pretty green back then. But that experience permanently put me off from any interest in that company. It would seem Google HR / Recruiting hasn't improved in all these years.
- mindfulplay 8y ago
  To be fair, if any company hired you based just on your app, it would be unfair to you and the company. Most software companies thrive because of generalist SWEs who need to demonstrate consistent performance. It might be that the app was a foot in the door but might not be applicable past that initial point
  - johannes1234321 8y ago
    Well, maybe they also hire to own the app and the user base behind it or some technology in it.
  - waisbrot 8y ago
    I mean, you maybe wouldn't just send an offer letter to someone who wrote an app, sure. (But depending on what they wrote, maybe you would. Something reasonably large and open-source, where they ended up incorporating a substantial amount of code from other contributors?) But if someone's got 30kloc sitting there, why wouldn't you look at that body of work instead of starting from scratch with "please write FizzBuzz on this whiteboard"?
charleslmunger 8y ago
Plenty of discussion on the first time this was posted: https://news.ycombinator.com/item?id=12701272 https://news.ycombinator.com/item?id=12701272
- minimaxir 8y ago
  That was posted in 2016, so this submission qualifies as new content. (it doesn't feel like over a year though!)
zeroxfe 8y ago
This is the pre-screen, very likely conducted by a poorly-trained (or incompetent) recruiter. IIRC, there is a ton of room for response variety in the answers, and the screeners are trained to handle them (obv. very difficult to do well.) The pre-screens are act as first-pass filters before the actual interviews (conducted by engineers.) Google does many hundreds (if not thousands) of these a week, and this false-negative is an unfortunate casualty of the process.
- madamelic 8y ago
  >this false-negative is an unfortunate casualty of the process I wouldn't call it a "false negative" if your recruiters are completely incapable of filtering correctly. It's a false negative if someone has an off day. It is an error in your hiring process if it purposefully filters out people who get their hands dirty and can talk nuance.
  - dmoy 8y ago
    They mean false negative from a statistics point of view, which is what this literally is (if we take the author's assumption that they're qualified at face value). A false negative is an error in the process.
    - waisbrot 8y ago
      madamelic is saying that the described interview process would select against qualified candidates because some of the items on the answer sheet are flat-out wrong. Analogy would be if we were evaluating a blood-pressure drug, but our BP-measurement cuff was miss-calibrated and all readings were -10 from reality.
      - skj 8y ago
        And all examples in question would be labeled "false negative"s.
- onion2k 8y ago
SA500 8y ago
This has been posted before. Standard questions from a recruiter. The fact he wasn't able to work out how to play the game at this stage suggests he probably would have been cut out for the job anyway...
neurobashing 8y ago
I got the same test for an SRE gig just a couple years ago. Amazon fizzbuzz'd me on the first coding test before I even went on-site. I know both have very stellar hiring reputations and employ a ton of smart people but from my "man on the street" experience, it felt more like a test of answering the right questions than a test of skill. the best tech interview I've ever had was at a company that didn't make me write a line of code, instead preferring a lengthy conversation about coding. On reflection it was a far more grueling test of knowledge than "implement a hash table in C, you have 35 minutes".
bonestamp2 8y ago
It's like answering riddles for a troll under a bridge.
- hpcjoe 8y ago
  Paraphrasing from Monty Python's Holy Grail ... "Answer these questions three, and a GOOG employee you shall be!"
richmarr 8y ago
This would be better implemented as a multiple choice test... at least that way there'd likely be no quibbling over whether an inode is "metadata" or an "identifier" But of course they wouldn't implement it in such a way.
sidlls 8y ago
What an absurd test. However I'm more concerned that a "Director of Engineering" position has these sorts of questions as a phone screen. Especially at Google, which has no shortage of applicants for IC positions who would actually be doing this work in any healthy and sane engineering organization. Does "Director of Engineering" at Google actually mean "Software Engineer"? Is this like in Finance where everyone is a Vice President of something?
DrNuke 8y ago
Google hat or not, monkeys are still monkeys, but this case shows a problem that is very common to all the employee positions, from the very bottom to the very top: all monkeys must watch, hear, talk and jump to get their peanuts.
organicmultiloc 8y ago
I interviewed at Google a million years ago and got the same sort of "trivia list", which was surprising to me. I passed most of them and everyone seemed excited about me while I was there, but then I started criticizing the interview process and (more importantly) Google Finance as being pretty bad, and this really upset everyone. I could tell they weren't used to ever being criticized, pointing out how the interview process had effectively zero behavioral aspects or problem solving questions, as well as all the gaps between one of their products and the competition, and they did not give me an offer. The funny part is they incorporated much of my feedback into Google Finance years later. It's still a mess, but hey at least they made some progress.
- ionforce 8y ago
  > then I started criticizing the interview process and (more importantly) Google Finance as being pretty bad, and this really upset everyone. Not rocket science, everybody. Who knew that people don't respond well to being criticized by strangers! Nobel Prize.
  - devilmoon 8y ago
    Guess we found the Google Finance developer on HN
  - be_jenk 8y ago
    Typically socially well-adjusted people can accept criticism on a project/product without taking it personally
    - organsnyder 8y ago
      Depends on the context and how it is delivered. If a job applicant started talking about my team's product "being pretty bad", that would be a red flag—I can only imagine what their code-review style would be like.
  - AboutTheWhisles 8y ago
    I would be excited if someone criticized what I am working on if they were planning on being part of the solution
wyldfire 8y ago
> Recruiter: that's not the answer I have on my sheet of paper. When I got a similar screening from GOOG, the recruiter confessed upfront to having these technical questions scripted and seemed much more flexible than this particular one. > 7. what is the name of the KILL signal? The question might have been "what is the default signal sent by 'kill'?" The answer to that question is SIGTERM and not SIGKILL. The recruiter may have asked it wrong, the question may have been written vaguely for the recruiter or the interviewee may have misunderstood/misheard the details of the question.
- geofft 8y ago
  Also, if you can't have enough of a conversation with someone who's unfamiliar with the "kill" command to figure out exactly what signal they have in mind even when they're using the wrong words, and without getting upset at them or deciding that they're beneath you, you're not qualified to be a director of engineering.
  - jerf 8y ago
    That is true, but on the other hand, if the person reading the script stands on the wording of the question, as soon as they read the "correct" answer you've lost. There's now no recovering, because "obviously" now that you've heard the right answer you're just spinning to explain away your failure. (As with others, I will stipulate that accuracy in this report may not be 100%, but I'm not necessarily willing to assign it 0% either, especially as I've encountered people like that myself.)
    - geofft 8y ago
      So the trick is to not answer the question immediately if you're unsure, but ask to clarify. Which, again, is a good skill in life (as an IC, and certainly as a director of engineering). If you're reviewing your coworker's code and they got something wrong, asking "Can you clarify what you meant here" will go over ten times better than "You're wrong" (and a hundred times better if they're not in fact wrong). Maybe this is a bug in human cognition, sure, but at a Google-sized company you can't get anything technical done without interfacing with buggy humans on a regular basis. "The KILL signal? So you're calling the kill function with KILL as an argument, or typing kill dash KILL, or...?" would have cleared up the confusion immediately, because even a screener unfamiliar with the material would have said "Oh, that's not what I'm asking." I do strongly believe that the questions as written down are not as reported in this blog post, because there are tons of other sources who have written about being asked this question in an initial screen, and they all phrase it as "What is the signal that the kill command sends."
tluyben2 8y ago
I have no idea at all why people want to work for these kind of companies if that is the entrance criteria; especially with that kind of seniority and being abused like that. Was Norvig doing these tests I wonder? I do think people overestimate the importance in their life of working for a company like that.
4684499 8y ago
Silly question maybe, is there any chance they do this on purpose?
- paulcole 8y ago
  Zappos has high-level candidates be interviewed by lower-level employees. This is a test to see how they interact with and treat another person who's not on their "level." Wouldn't be surprised if this is something similar. Acting like the smartest and most important person in the room is rarely a good look, even if you are.
_Marak_ 8y ago
Google hiring has been fubar for years now. I think many of us here have been contacted ( unsolicited ) by Google for job interviews in the past. My Google interview story ends with me stopping the 8th interview ( 4th technical interview ) half-way in due to the frustration of listening to my interviewer loudly reply to text messages on his phone while I'm trying to write very complex source code into a shared Google Text Document using no other development tools. At one point the 8th interviewer asked me if I had ever used Github before. Considering Google cold-contacted me on my public Github email address and half my resume was Github projects it was obvious this guy didn't even look at my resume...
- s17n 8y ago
  I make it a point to not read resumes unless I'm supposed to be asking questions about their contents, to avoid bias.
  - crispyporkbites 8y ago
    Is this sarcasm? You just make your entire hiring call on talking to the person without looking at their career, academics and skills?
    - sjsjxhhc 8y ago
      If you’re one person out of many in the hiring process, and your role is to evaluate some specific skills, then yes, it may well be the case that knowing more about the candidate’s background will hurt more than it helps.
      - s17n 8y ago
        Exactly
    - psyc 8y ago
      I doubt it's sarcasm. I've often lamented that as a 30-year 'veteran' I'm still often treated as though I'm probably incompetent, until proven otherwise beyond a reasonable doubt. Some people do ignore my CV. I know that some people believe this is right and necessary because you can't trust anyone. I believe it's a travesty in this industry, and if I am treated this way, I'm walking straight out the door and into my next opportunity.
w8rbt 8y ago
Same experience here with the trivia questions. They called me out of the blue about 10 years ago and said they wanted to interview me. So I said OK. Later, during the interview, the questions were largely trivia. How do you remove a file using the rm command when the file is named -f? I was like, what sane person would name a file -f? Anyway, after I got over the shock of the question... you can ./-f, use the absolute /path/to/-f or -- -f and maybe other ways too.
- rorykoehler 8y ago
  Surely the correct answer is you Google how to do it!?
  - jstimpfle 8y ago
    These questions are supposed to work as a proxy for experience. Everybody can google the answer to trivia, but if an applicant doesn't know the answer by heart that's an indication for lack of experience.
    - crdoconnor 8y ago
      Except it's a terrible indicator and an abysmal proxy.
      - jstimpfle 8y ago
        Why is that?
    - rorykoehler 8y ago
      I still google things i know how to do that i don't use often because it's quicker to copy and paste than to try remember details that are vague in my memory. The example given is exactly one of those cases. Even Jeff Atwood tweeted that he does this the other day.
      - jstimpfle 8y ago
theDoug 8y ago
This again? https://hn.algolia.com/?query=Google%27s%20%E2%80%9CDirector%20of%20Engineering%E2%80%9D%20Hiring%20Test&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0 https://hn.algolia.com/?query=Google%27s%20%E2%80%9CDirector...
pbnjay 8y ago
I had a similar experience in 2013, which while I passed the screen it only ended up matching me to SRE roles. I have PhD in CompSci so that was pretty disappointing so I did not bother scheduling an onsite. My more recent experience was a lot more positive, the screen is much more conversational and coding-based and not a test of wrote memorization of CS trivia. I don't know if this is due to changes in the past 5 years or the recruiters being from different teams.
pfarnsworth 8y ago
This sounds like an old post. Google recruiting was really terrible 10 years ago but these days it’s just bad or okay sometimes. I would be shocked if they asked potential directors of engineering these questions today.
geofft 8y ago
This was posted previously, in October 2016: https://news.ycombinator.com/item?id=12701272 https://news.ycombinator.com/item?id=12701272 An actual Google director of engineering pointed out that these are individual-contributor SWE/SRE questions (and I can attest I got very similar questions as a new college grad). As I commented previously: "Reading more closely, it sounds like they are not interviewing him for a director of engineering position; it just sounds like he thinks his current role, CEO-who-writes-code of a very small software company (http://www.gwan.com/about http://www.gwan.com/about), qualifies him for a director-of-engineering-level position. He's probably being interviewed for an SRE team lead or thereabouts." Also, a ton of this conversation makes a lot more sense if you make the assumption that the interviewee is misremembering the questions: https://news.ycombinator.com/item?id=12702726 https://news.ycombinator.com/item?id=12702726 (Which is a very gentle assumption, if the interviewee also mistakenly thought they were being interviewed to be a director of engineering.) In which case, screening out someone with an inflated sense of their own experience and overconfidence that the stupid person on the other end of the phone is stupid is exactly what this process is supposed to do.
- DannyBee 8y ago
  and i just commented the same thing i did then, because i completely didn't notice this was from 2016 :)
- waisbrot 8y ago
  > He's probably being interviewed for an SRE team lead or thereabouts OK, but incorrect/inflexible quizzing about tech questions is inappropriate full stop. If this was an interview for SWE summer intern it'd be a badly-run interview. > exactly what this process is supposed to do You can't ensure that there will be no hurt feelings ever, but ideally the candidates you fail don't go around talking about how poor your interview process is. > make the assumption that the interviewee is misremembering the questions In your post you imagine slight differences that might make the questions more reasonable. I think the main problem here is the responses to the answers. For a non-engineer quizzing someone, the response to an answer should be "OK" and then you note down the answer and show your notes to an engineer at the end. This solves both the "that's not what's written on my sheet" problem and also allows the interviewee to form a more nuanced impression of your recruiting process.
hpcjoe 8y ago
I had, literally, the exact same test. Only really missed the bit counting as I brute-forced it (phone screen after all). Was interviewing for a similar position. Was not advanced after on-site. Had a mix of good and bad on-site people. Interviewer quality, viewpoint, attention all factor in, and in about 1/2 the cases, I had a strong vibe from them that they were disinterested in the process/person. I could comment on whether or not I thought their process actually produced superior results or not, and how they would measure. I'll say it is at least a small step up from their previous brain teasers. Hopefully, they will continue to refine their processes.
compumike 8y ago
(Disclosure: I'm an engineer & interviewer at Triplebyte) These false negatives are avoidable with a better-designed screening process. This "exact match" issue is why we use multiple choice questions (pick from 4 choices) for initial technical screening. If you know what you're talking about, the format is far more forgiving to all of the cases described in the post, as you can rule out obviously incorrect answers. If you don't know what you're talking about, your odds of doing well are are stacked against you after a few questions. Once you're doing a video interview with one of our engineers, we know what makes sense, can ask follow-up questions, and if you plausibly know more than we do about a topic, can make a note to look things up or ask our teammates in #interviewers. (Note: we're hiring remote engineers to grow our interview team: https://news.ycombinator.com/item?id=16815444 https://news.ycombinator.com/item?id=16815444 )
tzs 8y ago
> There's an array of 10,000 16-bit values, how do you count the bits most efficiently? I would have said that I would multiply 10000 by 16. Oh well, no Google job for me I suppose.
- poxrud 8y ago
  I find that the solution to a lot of these trick interview questions is to use a hash table or some kind of a look up table. Even the famous google mock interview video uses a hash table in the solution. The solution to this question is to use a 256bit lookup table. You'd need to precompute the lookup table that will give you the bit count of every possible bit combination in a byte. Then traverse your 10,000 long array, use your lookup table to count the bits and add them to your total.
  - tzs 8y ago
    Assuming that they want the number of 1 bits (the question asked for the number of bits, not the number of 1 bits--hence my answer), it is not obvious to me that a lookup table is the fastest. Given an unsigned 32-bit value, v, this well-known bit hack [1] counts the number of 1 bits: v = v - ((v >> 1) & 0x55555555); v = (v & 0x33333333) + ((v >> 2) & 0x33333333); count = ((v + (v >> 4) & 0x0F0F0F0F) * 0x01010101) >> 24; If you can treat the 10000 16-bit values as 5000 32-bit values, applying the above 5000 times might be as fast or faster than applying the table lookup method to 20000 bytes. It will depend on precise details of the particular computer on which it is run. [1] http://graphics.stanford.edu/~seander/bithacks.html http://graphics.stanford.edu/~seander/bithacks.html
  - rurban 8y ago
    Nope, hardware is better. Throw popcount at it, in parallel. ispc will help you with the parallel bit if your compiler cannot autovectorize good enough.
- zpatel 8y ago
  If one was going to be hired to work on cloud API or some enterprise tool, not sure how this low question would qualify someone as a better software engineer.
nimbius 8y ago
ive had 3 google interviews, one on-site, and I can say without a doubt that its not only demoralizing but a complete waste of time. Reading their own outline of the hiring process and watching the youtube video, I was instructed that "goofy" google questions weren't asked anymore. No less than 5 minutes in the meeting room and I was met with "how do you build a datacenter on the moon?" followed by "how many cans of beer can you fit in a school bus?" My latest phone screen about a year ago started off with a technical recruiter handing off from Mountain View to a recruiter in San Diego, then passing me back to a technical screener in mountain view who couldnt remember his questions. The follow-up technical review came from Boulder Colorado and focused on C programming and Linux dynamic libraries for a SRE position. All in all I hope they get their hiring process sorted out. The most disparaging and frustrating thing is hearing "just keep trying! everyone has to apply at least N times before they get hired." The fact that this sentiment exists at all speaks volumes to the management climate.
- mirceal 8y ago
  how many cans of beer can you fit in a school bus parked inside of a datacenter on the moon?
AboutTheWhisles 8y ago
A lot of these were the recruiter having no understanding of what they were asking, but the bit counting is just nonsense. A lookup table requires an extra memory access that by its nature is incoherent. Contrast that to being able to read the memory straight through and having it prefetched, then using the popcnt instruction: https://www.felixcloutier.com/x86/POPCNT.html https://www.felixcloutier.com/x86/POPCNT.html
- compumike 8y ago
  Accessible as __builtin__popcountll(unsigned long long) in gcc or clang. Especially handy if you're writing a chess bot.
- zeusk 8y ago
  > A lookup table requires an extra memory access that by its nature is incoherent. Pedantic but, the LUT would also remain in the cache if there wasn't some issue with cacheline contention. Although, I do agree that POPCNT + prefetch and unrolling will do much better.
  - AboutTheWhisles 8y ago
    I thought the same thing, although I've tried LUT approaches to other problems like gauss curves and the results were much slower than I expected. The LUT may stay in the L2 cache, but whatever was going on, there was actually a big discrepancy between looking values up and just calculating the gauss curve equation even though it had exponents on floats.
DannyBee 8y ago
So, as part of my job, I have been the hiring manager for directors for Google (3 in the past 6 months), and recruit quite a bit. This was a simple phone screen, and it seems the recruiter was not given a good set of questions. However, I actually doubt it was really a director of engineering screen, despite this person's experience level (maybe it should have been, but ...). I say this because I know a lot of the leadership recruiters, (it's a separate thing from regular SWE/manager recruiting), and I know how the process works. They don't screen candidates this way normally precisely because it doesn't make sense. (Whatever you may think of Google's regular non-leadership recruiting :P) Instead, they ask question directly relevant to what the hiring manager wants/needs (IE i give them the questions to use), and in most cases, do just enough to know whether it would be a waste of time for the hiring manager to talk to them. At which point, a hiring manager like me talks to the candidate and decides whether to bring them in for onsites. This particular set of questions seems closer to standard non-leadership SRE questions.
- DannyBee 8y ago
  It turns out this post is from 2016 and i already said the exact same thing then: https://news.ycombinator.com/item?id=12701272 https://news.ycombinator.com/item?id=12701272
  - dman 8y ago
    DannyBee discovered to be idempotent.
    - juancampa 8y ago
      Functionally pure
- fjsolwmv 8y ago
  I thought Google hires into a general pool, and hiring managers don't "own" candidates like Amazon HMs do.
  - 8y ago
nateburke 8y ago
I had the opportunity to speak with someone who was on the hiring committee at google when the company scaled from ~5k employees to ~20k employees. This was the committee of people in charge of designing the interview funnel though I'm not sure if it was for engineering, specifically, or the whole company. He said that there were two very large compromises that had to be made in order to hit those growth numbers: 1. Near-total reliance on gpa and school prestige for entry-level position initial resume screening 2. Relaxation of membership controls on the internal pool of people at Google qualified to administer the "is googley?" culture fit interview I would not be surprised if "allowing non-technical people to pre-screen technical people" is a similar growth-forward HR compromise made, resulting in the OP's suboptimal experience.
bootloop 8y ago
Interesting. My Google Interview started with 1h interviews with two Software Engineers (who were working on Google AdWords) They asked mostly data structure questions and gave a short exercise which I had to solve. The first engineer had obviously lack of exp and interest in this process, the second one was a lot more pleasant to talk to and I felt a lot more comfortable. (Unrelated to my actual performance which was properly not good enough in any case.)
deleted 8y ago
[deleted]
utopcell 8y ago
I would have gently ended the interview the moment he mentioned using 64-bit lookup tables to count bits 8 bytes at a time.
pfarrell 8y ago
In my experience and from what I've gleaned from the outside, recruiting at Google consists of shoveling as many bodies into the pipeline every week to allow the top few to get picked for an onsite interview where it doesn't matter if they say no to everyone because there are always more applicants next week. After getting through phone interviews and getting flown out to SF for an interview at youtube, I made the mistake of thinking I was like 95% of the way through the process. At google (and I suspect a few of the other megacorporations), getting to onsite interviews means you now in the lottery with similar chances.
qooiii2 8y ago
Google asked if I would do a phone screen a few years ago for an SRE position, and I thought that process was hilarious. In my case the questions had nothing to do with my background (microcontroller firmware for sensors) and it was only by incredible luck that I could answer them. For example, I had just read about some data structure the day before. The recruiter didn't spend much effort telling me what the job was or why I should consider leaving my current great position for it. I said, "no thanks!" when I found out what an SRE actually does. It seems like Google's interview process is designed to measure how much a candidate wants to work at Google. This is probably okay for them, but it's going to result in them overpaying for good people.
nfRfqX5n 8y ago
my interview process spanned 5 months between all of them. really wasn't fun trying to have a convo and answer questions while the interviewer types down every word you say. seemed very robotic. you get almost no feedback for spending all of that time, so you don't really know where you went wrong or how to improve. i understand they can't say anything due to the possibility of a lawsuit, but they should be able to figure something out with that
deleted 8y ago
[deleted]
CodeSheikh 8y ago
Yes this guy might have an inflated complexion of a self-claimed all-star but to be honest Google and all big tech companies have really frustrating recruiting process and most of the time interviewee's frustrations go unheard. So this guy took the only approach that he could think off, is to take his plea to the internet.
Molaxx 8y ago
It seems Google is more sensitive to false positive than false negative because of their very good compensation and the relative high demand for Google jobs + the unbalanced high costs of a false positive. At their scale they can afford playing the stats and not be bothered with individuals. Further more any promising rejected engineer will be asked to try again every six months which alleviate the false negative problem. seems reasonable from this perspective.
oldgun 8y ago
Seen this piece before, still funny to me. > Thought: I guess that's what happens when AI bots discover recreational drugs. That's why engineers should be interviewed by engineers.
LordHumungous 8y ago
The recruiter asked me a lot of these same questions when I was applying to an SDE position
jroseattle 8y ago
We experienced the same type of issue with my company, and decided to try to address it. First, our problem statement: filtering phone-screens by recruiters is resulting in poor experience, false positives, etc. We thought about potential causes, but instead opted to look at the logistics of the call: recruiter runs process, gets responses, and then returns to engineering with feedback. It was a vacuum filled with innuendo, unspoken assumptions, you name it. Collectively, our recruiting operation was an echo chamber. So we asked if we could have recruiting calls recorded and/or transcribed. Candidates had no problem agreeing to it -- the recruiters were reluctant at first. (You can probably guess where this going...) We recorded/transcribed maybe five calls, and that's all that was necessary. We saw dramatic improvement, and we owe most of that to the Observer Effect. We maintained the same throughput of candidates, but we saw more ideally-suited candidates pass through as well as heard better experiences from candidates. I'd suggest most any operation try this.
- jvreagan 8y ago
  Love the idea, thanks for this!
trevor-e 8y ago
Unrelated to the main point of the article, but I really hate when people point out "been programming for XX years, since I was 6 years old!!" Years of experience does not equate to being a skilled programmer. I could play basketball for 40 years and be way worse than Lebron James was in middle school. Experience is important for other reasons.
- wolco 8y ago
  Translate the above to NBA coach. Very few high school coaches exist. Experience matters not raw strategic skill.
ksk 8y ago
I sense a little bit of CS ego in the interview. "Let me show you how you're not even qualified to take this interview" is never a winning strategy in any business scenario. Being able to read a person, and giving them an appropriate response is an important skill. After the first couple of responses it was pretty clear that the recruiter was only interested in cookie cutter answers. If you don't want to work at Google why even take the interview? And if you do, why would you care if a recruiting agency paper pusher asked you some dumb questions?
maxk42 8y ago
This pisses me off so bad: Quicksort does NOT have "the best big-O". It's big-O time complexity is O(n^2). Big-O refers to the worst case time complexity. Quicksort will on average take (n log n) time complexity, but that's not its big-O, that's its big-Theta. Some try to skirt this by saying "if you randomize the order of the data first, it will be sorted in big-O of n log n" but again, that's the average time complexity, not the pathological case. A lot of CS books teach this wrong. Please stop being wrong: O(Quicksort) is O(n^2)
- bmcfeeley 8y ago
  Big-Theta is not an average case, it is a special form of Big-O and Big-Omega wherein the worst case is also the best case from a complexity perspective. This is sometimes true in sorting since comparison based sorting cannot be improved beyond n*log(n) except in specific cases for specific domains. You are absolutely on the money about worst case being O(n^2) though for quicksort.
  - maxk42 8y ago
    I stand corrected. Is there a notation for "average" complexity?
    - bmcfeeley 8y ago
      Not that I'm aware of! As you've seen, I see Big-O abused into shorthand for "on the order of" to the effect of "average case is O(nlog(n))"
lisper 8y ago
My Google phone screen circa 2013 went something like this: for (i=0; i<NUM_QUESTIONS; i++) { Interviewer: [Technical question] Me: [Answer] Interviewer: That's right! } Followed by: Interviewer: You do understand that the position you have applied for is a managerial position, and that you're going to be dealing with schedules and budgets and not anything technical. Is that really what you want to do with your life? Me: Um, no, not really. Interviewer: OK, well, have a nice day then. Good bye.
- ScottBurson 8y ago
  ?? But you had worked there before, right? Didn't they remember you?
  - lisper 8y ago
    > you had worked there before, right? Yep. :-) > Didn't they remember you? If they did, they hid it well.
booleandilemma 8y ago
It’s obvious from this interview that Google is looking to hire a robot. If they were looking for a human they would have used a captcha.
urda 8y ago
I'll repost this again: https://news.ycombinator.com/item?id=12701858 https://news.ycombinator.com/item?id=12701858 This is a bullshit article, why did it frontpage again ?
- scottydelta 8y ago
  it might be a bullshit article but the horrible experiences of so many people in this thread cannot be bullshit.
jason_slack 8y ago
One of my interview questions: Interviewer: What is the difference between a mutable and immutable string? Me: A mutable string can be changed. A immutable string cannot be changed. Interviewer: Nope, think mutations. Mutable string can be mutated. Me: Mutated? Altering DNA? Interviewer: If you don't know this there isn't any sense in asking more difficult questions. Me: Floored.
- mirceal 8y ago
  follow up: do you know that everyone is a mutant?
  - jason_slack 8y ago
    Sadly when she said mutation I thought about the Teenage Mutant Ninja Turtles :-)
- itronitron 8y ago
  I hope you didn't list String expertise as one of your technical skills.
  - jason_slack 8y ago
    Explain?
    - itronitron 8y ago
      It is a joke, as so many interviewers complain that people lie about their technical skills and experience, if you listed String as a technical skill and the interviewer thought you didn't know what a mutable String was then they would conclude that you lied about your skill set. Hopefully you can see the humor. I feel your pain so can understand why you might not think it is funny.
      - jason_slack 8y ago
        I thought it was a joke but then I talked myself out of it :-) Yeah interviews have been rough this time around. Before this I hadn’t interviewed in 10 years.
throwaway84742 8y ago
Many people don’t know this but quicksort is actually _quadratic_ in the worst case, and it’s pretty easy to hit the worst case. Quadratic complexity is pretty bad for a sort.
axaxs 8y ago
This is nearly exactly the same set of questions I was asked for an SRE position. My favorite of which, was 'what is not in a linux inode'. That was the full question. My answer was sarcastic, and it didn't land well. Who interviews the interviewers?
icedchai 8y ago
This is a basic phone screen, not a "director of engineering" specific thing. I had a similar screen for an SRE position.
s2g 8y ago
I'm just wondering why this guy wanted to work for Google at all.
rurban 8y ago
I got the same. I found it hilarious how stupid the first rounders can be. But looking at the code this company produces and how management works confirms the bias.

569 points by josephscott 8y ago

> Me: on which kind of CPU? Why not let me compare my code to yours in a benchmark? While I agree that this is the right answer, questions regarding "Big-O" are trying to find out whether or not you can evaluate the complexity of an algorithm. If you can, you have some hope of writing different useful benchmarks that could be compared, where sometimes you can see orders of magnitude of improvement. If you can't, you might be just blindly tweaking the code to get 1-5% improvement from compiler flags, assembly optimizations, etc. In practice this recruiter might be bad at their job by binding themselves so rigidly to the script.

jerf 8y ago
"While I agree that this is the right answer, questions regarding "Big-O" are trying to find out whether or not you can evaluate the complexity of an algorithm." Most algorithms for counting bits will be O(1) for a given int, so O(number of ints) for a list of ints. Algorithms that aren't O(1) for a given int [1] will still be essentially O(1) since the upper bound would be so tight. So I don't think that was a Big-O question. [1]: "count = 0; while i != 0 { count += i % 2; i >> 2 }". Technically this is O(leftmost set bit), but on a fixed-bit int could be considered O(1) with a suitable constant. Note that algorithm isn't entirely pointless; it works on bigints too, so in something like Python where ints and bigints are not distinguished by type you could use it as a fallback for "generic int" (which may include user-defined classes). (Though of course there are ways to speed it up.)
SilasX 8y ago
Well, I've been in this scenario before, and have resorted to that. I was this guy [1]. (Interview question in link, I had written a solution.) The interviewer stubbornly insisted that the run time was n^2 because it had an inner loop. (Never mind that the inner wasn't looping over pairs with the bigger loop, but just the bits within that element.) I went through a number of heuristics to convince him otherwise: what if you doubled the list, how would that analytically affect the run time? What if the elements were bigger? (as you can find from the reddit thread) Disturbingly, I asked him what he would need to see to convince him that the code I wrote was O(n), and he said, "no inner loop", which reveals a profound misunderstanding of both the issue at hand, and how to resolve disagreement. At that point, I resorted to saying, well, let's run the code with increasing input size and see how it scales (which would give valuable information about its actual scaling behavior). Then he refused, left the room, and told the director to veto me from the rest of that day's interviews. [1] https://news.ycombinator.com/item?id=6070001 https://news.ycombinator.com/item?id=6070001
- wyldfire 8y ago
  > Then he refused, left the room, and told the director to veto me from the rest of that day's interviews. "Bullet dodged" -- he did you a huge favor.

ebikelaw 8y ago

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

jschwartzi 8y ago

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

outside2344 8y ago

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

pinewurst 8y ago

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

ThePadawan 8y ago
I'm in a similar boat - I've been approached twice in the past, and both times went on to the onsite interview day only to be told "We are unsure whether we want to hire you, so we will err on the side of caution and ask you to come back in a year". However, I am still getting contacted randomly by their recruiters without any indication why I should invest energy to try again - the result will generally the same. Getting an answer to that question also turned out to be impossible, since I only got stock answers back. Really shameful for a company which (at least in my perception) prides itself on celebrating an engineer-driven culture (instead of one driven by HR).
logicallee 8y ago
This is similar to taking standardized tests where you are smarter than the question-writer. What would you select as the answer to the following question: " x is an integer. If x² = 16, then x =? A. 1. B. 2. C. 4. D. 16. E. Not enough information. " Think hard and tell me what you would select. For me it is VERY clear that I have to select C, 4. It is just as clear that it is the wrong answer, and the correct answer is E, because x can be -4 or 4, and you do not have enough information. How do I know to select C? Mostly, from the context. "x is an integer" is a weird and stupid way to begin a question like that, the whole question is pretty stupid. The choices are just natural whole numbers, and ones that someone might select. Still, the question has a VERY clear correct answer, which is E. It is not the answer you should select. Likewise if you are being given a technical interview by someone reading stupid template questions, then you need to figure out how dumb the template is, and answer on that level. It's not about being correct. The question "standardized test" I just made up and answered should be answered incorrectly. Don't answer questions like that correctly.
- 8y ago

koolba 8y ago

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

pinewurst 8y ago
I was asked to regurgitate Linux header file constants. I believe Google is attempting to push the boundaries of self-parody as they push computer science.
geofft 8y ago
The interviewee's answer to the inode thing is simply wrong. An inode is metadata (or "attributes", sure): it's not an index or an identifier. I think the interviewee is thinking of the inode number, which is a related but different thing. The interviewer was right.
- psyc 8y ago
  http://www.linfo.org/inode.html http://www.linfo.org/inode.html I swear this is about the 20th time in a week I've seen a good comment (the parent) in the gray. Unless I'm imagining things, this has been happening with extremely noticeable increasing frequency. I've held off saying anything about it for days while it keeps happening more and more.

draw_down 8y ago

I’m not sure I could take more than a couple of those extremely petty replies from the interviewer before I would just tap out. Why even bother having this interview conducted by a human when they display as much nuance and understanding as a Scantron? “Quicksort is the best sort, period.” Fuck off.

eitally 8y ago

> Recruiter: that's not the answer I have on my sheet of paper. This is the problem. Google hires as such ridiculous volume (onboarding >5000 people last quarter, and on average growing at ~10000 employees (FTEs) per year) that the process gets abstracted into whatever Google thinks can be done algorithmically. This makes almost no sense for most roles, including any type of specialist as well as middle/senior management, and you end up with situations like you faced. If it makes you feel better, it's equally frustrating for hiring managers, who just get input from recruiters that so-and-so failed the phone screen. I'm at the point where I tell my recruiters to let me do the phone screens myself whenever they come across what -- on paper -- looks like a strong, viable candidate. <banghead>

itissid 8y ago
Reminds me of the time a TSA person at the airport asked a programmer at the port of entry to answer some canned CS questions from wikipedia and expected the exact answers...
- cordite 8y ago
  Could you find the source for this?
  - lxhrstn 8y ago
    https://twitter.com/cyberomin/status/835888786462625792 https://twitter.com/cyberomin/status/835888786462625792
  - KboPAacDA3 8y ago
    https://www.wired.com/2017/03/immigrant-says-customs-quizzed-prove-can-code/ https://www.wired.com/2017/03/immigrant-says-customs-quizzed...
  - cabotmoose 8y ago
    Believe it might be this: https://www.wired.com/2017/03/immigrant-says-customs-quizzed-prove-can-code/ https://www.wired.com/2017/03/immigrant-says-customs-quizzed...

andrew_ 8y ago

Tossing my hat in the ring with a similar experience. Was approached in 2003 because of an app I had written that got attention, and was told that Googlers wanted to speak with me about the app. What followed was three calls with gate-keepers of sorts, between which there was zero knowledge transfer from call to call. None of them inquired about the app and all of them asked questions so unrelated to the app that they might as well have been interviewing me for a position writing Sanskrit. On the last of the 3 calls I asked the interviewer when someone was going to inquire about the app, to which the person replied that they had no idea what it was and that they were told I had applied for a position. Though they couldn't tell me what that position apparently was. I kindly requested they not contact me again. I'm no all-star, I don't think I'm special, and I was still pretty green back then. But that experience permanently put me off from any interest in that company. It would seem Google HR / Recruiting hasn't improved in all these years.

mindfulplay 8y ago
To be fair, if any company hired you based just on your app, it would be unfair to you and the company. Most software companies thrive because of generalist SWEs who need to demonstrate consistent performance. It might be that the app was a foot in the door but might not be applicable past that initial point
- johannes1234321 8y ago
  Well, maybe they also hire to own the app and the user base behind it or some technology in it.
- waisbrot 8y ago
  I mean, you maybe wouldn't just send an offer letter to someone who wrote an app, sure. (But depending on what they wrote, maybe you would. Something reasonably large and open-source, where they ended up incorporating a substantial amount of code from other contributors?) But if someone's got 30kloc sitting there, why wouldn't you look at that body of work instead of starting from scratch with "please write FizzBuzz on this whiteboard"?

charleslmunger 8y ago

Plenty of discussion on the first time this was posted: https://news.ycombinator.com/item?id=12701272 https://news.ycombinator.com/item?id=12701272

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

zeroxfe 8y ago

This is the pre-screen, very likely conducted by a poorly-trained (or incompetent) recruiter. IIRC, there is a ton of room for response variety in the answers, and the screeners are trained to handle them (obv. very difficult to do well.) The pre-screens are act as first-pass filters before the actual interviews (conducted by engineers.) Google does many hundreds (if not thousands) of these a week, and this false-negative is an unfortunate casualty of the process.

madamelic 8y ago
>this false-negative is an unfortunate casualty of the process I wouldn't call it a "false negative" if your recruiters are completely incapable of filtering correctly. It's a false negative if someone has an off day. It is an error in your hiring process if it purposefully filters out people who get their hands dirty and can talk nuance.
- dmoy 8y ago
  They mean false negative from a statistics point of view, which is what this literally is (if we take the author's assumption that they're qualified at face value). A false negative is an error in the process.
  - waisbrot 8y ago
    madamelic is saying that the described interview process would select against qualified candidates because some of the items on the answer sheet are flat-out wrong. Analogy would be if we were evaluating a blood-pressure drug, but our BP-measurement cuff was miss-calibrated and all readings were -10 from reality.
    - skj 8y ago
      And all examples in question would be labeled "false negative"s.
onion2k 8y ago

SA500 8y ago

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

neurobashing 8y ago

I got the same test for an SRE gig just a couple years ago. Amazon fizzbuzz'd me on the first coding test before I even went on-site. I know both have very stellar hiring reputations and employ a ton of smart people but from my "man on the street" experience, it felt more like a test of answering the right questions than a test of skill. the best tech interview I've ever had was at a company that didn't make me write a line of code, instead preferring a lengthy conversation about coding. On reflection it was a far more grueling test of knowledge than "implement a hash table in C, you have 35 minutes".

bonestamp2 8y ago

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

hpcjoe 8y ago
Paraphrasing from Monty Python's Holy Grail ... "Answer these questions three, and a GOOG employee you shall be!"

richmarr 8y ago

This would be better implemented as a multiple choice test... at least that way there'd likely be no quibbling over whether an inode is "metadata" or an "identifier" But of course they wouldn't implement it in such a way.

sidlls 8y ago

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

DrNuke 8y ago

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

organicmultiloc 8y ago

I interviewed at Google a million years ago and got the same sort of "trivia list", which was surprising to me. I passed most of them and everyone seemed excited about me while I was there, but then I started criticizing the interview process and (more importantly) Google Finance as being pretty bad, and this really upset everyone. I could tell they weren't used to ever being criticized, pointing out how the interview process had effectively zero behavioral aspects or problem solving questions, as well as all the gaps between one of their products and the competition, and they did not give me an offer. The funny part is they incorporated much of my feedback into Google Finance years later. It's still a mess, but hey at least they made some progress.

ionforce 8y ago
> then I started criticizing the interview process and (more importantly) Google Finance as being pretty bad, and this really upset everyone. Not rocket science, everybody. Who knew that people don't respond well to being criticized by strangers! Nobel Prize.
- devilmoon 8y ago
  Guess we found the Google Finance developer on HN
- be_jenk 8y ago
  Typically socially well-adjusted people can accept criticism on a project/product without taking it personally
  - organsnyder 8y ago
    Depends on the context and how it is delivered. If a job applicant started talking about my team's product "being pretty bad", that would be a red flag—I can only imagine what their code-review style would be like.
- AboutTheWhisles 8y ago
  I would be excited if someone criticized what I am working on if they were planning on being part of the solution

wyldfire 8y ago

> Recruiter: that's not the answer I have on my sheet of paper. When I got a similar screening from GOOG, the recruiter confessed upfront to having these technical questions scripted and seemed much more flexible than this particular one. > 7. what is the name of the KILL signal? The question might have been "what is the default signal sent by 'kill'?" The answer to that question is SIGTERM and not SIGKILL. The recruiter may have asked it wrong, the question may have been written vaguely for the recruiter or the interviewee may have misunderstood/misheard the details of the question.

geofft 8y ago
Also, if you can't have enough of a conversation with someone who's unfamiliar with the "kill" command to figure out exactly what signal they have in mind even when they're using the wrong words, and without getting upset at them or deciding that they're beneath you, you're not qualified to be a director of engineering.
- jerf 8y ago
  That is true, but on the other hand, if the person reading the script stands on the wording of the question, as soon as they read the "correct" answer you've lost. There's now no recovering, because "obviously" now that you've heard the right answer you're just spinning to explain away your failure. (As with others, I will stipulate that accuracy in this report may not be 100%, but I'm not necessarily willing to assign it 0% either, especially as I've encountered people like that myself.)
  - geofft 8y ago
    So the trick is to not answer the question immediately if you're unsure, but ask to clarify. Which, again, is a good skill in life (as an IC, and certainly as a director of engineering). If you're reviewing your coworker's code and they got something wrong, asking "Can you clarify what you meant here" will go over ten times better than "You're wrong" (and a hundred times better if they're not in fact wrong). Maybe this is a bug in human cognition, sure, but at a Google-sized company you can't get anything technical done without interfacing with buggy humans on a regular basis. "The KILL signal? So you're calling the kill function with KILL as an argument, or typing kill dash KILL, or...?" would have cleared up the confusion immediately, because even a screener unfamiliar with the material would have said "Oh, that's not what I'm asking." I do strongly believe that the questions as written down are not as reported in this blog post, because there are tons of other sources who have written about being asked this question in an initial screen, and they all phrase it as "What is the signal that the kill command sends."

tluyben2 8y ago

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

4684499 8y ago

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

paulcole 8y ago
Zappos has high-level candidates be interviewed by lower-level employees. This is a test to see how they interact with and treat another person who's not on their "level." Wouldn't be surprised if this is something similar. Acting like the smartest and most important person in the room is rarely a good look, even if you are.

_Marak_ 8y ago

Google hiring has been fubar for years now. I think many of us here have been contacted ( unsolicited ) by Google for job interviews in the past. My Google interview story ends with me stopping the 8th interview ( 4th technical interview ) half-way in due to the frustration of listening to my interviewer loudly reply to text messages on his phone while I'm trying to write very complex source code into a shared Google Text Document using no other development tools. At one point the 8th interviewer asked me if I had ever used Github before. Considering Google cold-contacted me on my public Github email address and half my resume was Github projects it was obvious this guy didn't even look at my resume...

s17n 8y ago
I make it a point to not read resumes unless I'm supposed to be asking questions about their contents, to avoid bias.
- crispyporkbites 8y ago
  Is this sarcasm? You just make your entire hiring call on talking to the person without looking at their career, academics and skills?
  - sjsjxhhc 8y ago
    If you’re one person out of many in the hiring process, and your role is to evaluate some specific skills, then yes, it may well be the case that knowing more about the candidate’s background will hurt more than it helps.
    - s17n 8y ago
      Exactly
  - psyc 8y ago
    I doubt it's sarcasm. I've often lamented that as a 30-year 'veteran' I'm still often treated as though I'm probably incompetent, until proven otherwise beyond a reasonable doubt. Some people do ignore my CV. I know that some people believe this is right and necessary because you can't trust anyone. I believe it's a travesty in this industry, and if I am treated this way, I'm walking straight out the door and into my next opportunity.

w8rbt 8y ago

Same experience here with the trivia questions. They called me out of the blue about 10 years ago and said they wanted to interview me. So I said OK. Later, during the interview, the questions were largely trivia. How do you remove a file using the rm command when the file is named -f? I was like, what sane person would name a file -f? Anyway, after I got over the shock of the question... you can ./-f, use the absolute /path/to/-f or -- -f and maybe other ways too.

rorykoehler 8y ago
Surely the correct answer is you Google how to do it!?
- jstimpfle 8y ago
  These questions are supposed to work as a proxy for experience. Everybody can google the answer to trivia, but if an applicant doesn't know the answer by heart that's an indication for lack of experience.
  - crdoconnor 8y ago
    Except it's a terrible indicator and an abysmal proxy.
    - jstimpfle 8y ago
      Why is that?
  - rorykoehler 8y ago
    I still google things i know how to do that i don't use often because it's quicker to copy and paste than to try remember details that are vague in my memory. The example given is exactly one of those cases. Even Jeff Atwood tweeted that he does this the other day.
    - jstimpfle 8y ago

theDoug 8y ago

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

pbnjay 8y ago

I had a similar experience in 2013, which while I passed the screen it only ended up matching me to SRE roles. I have PhD in CompSci so that was pretty disappointing so I did not bother scheduling an onsite. My more recent experience was a lot more positive, the screen is much more conversational and coding-based and not a test of wrote memorization of CS trivia. I don't know if this is due to changes in the past 5 years or the recruiters being from different teams.

pfarnsworth 8y ago

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

geofft 8y ago

This was posted previously, in October 2016: https://news.ycombinator.com/item?id=12701272 https://news.ycombinator.com/item?id=12701272 An actual Google director of engineering pointed out that these are individual-contributor SWE/SRE questions (and I can attest I got very similar questions as a new college grad). As I commented previously: "Reading more closely, it sounds like they are not interviewing him for a director of engineering position; it just sounds like he thinks his current role, CEO-who-writes-code of a very small software company (http://www.gwan.com/about http://www.gwan.com/about), qualifies him for a director-of-engineering-level position. He's probably being interviewed for an SRE team lead or thereabouts." Also, a ton of this conversation makes a lot more sense if you make the assumption that the interviewee is misremembering the questions: https://news.ycombinator.com/item?id=12702726 https://news.ycombinator.com/item?id=12702726 (Which is a very gentle assumption, if the interviewee also mistakenly thought they were being interviewed to be a director of engineering.) In which case, screening out someone with an inflated sense of their own experience and overconfidence that the stupid person on the other end of the phone is stupid is exactly what this process is supposed to do.

DannyBee 8y ago
and i just commented the same thing i did then, because i completely didn't notice this was from 2016 :)
waisbrot 8y ago
> He's probably being interviewed for an SRE team lead or thereabouts OK, but incorrect/inflexible quizzing about tech questions is inappropriate full stop. If this was an interview for SWE summer intern it'd be a badly-run interview. > exactly what this process is supposed to do You can't ensure that there will be no hurt feelings ever, but ideally the candidates you fail don't go around talking about how poor your interview process is. > make the assumption that the interviewee is misremembering the questions In your post you imagine slight differences that might make the questions more reasonable. I think the main problem here is the responses to the answers. For a non-engineer quizzing someone, the response to an answer should be "OK" and then you note down the answer and show your notes to an engineer at the end. This solves both the "that's not what's written on my sheet" problem and also allows the interviewee to form a more nuanced impression of your recruiting process.

hpcjoe 8y ago

I had, literally, the exact same test. Only really missed the bit counting as I brute-forced it (phone screen after all). Was interviewing for a similar position. Was not advanced after on-site. Had a mix of good and bad on-site people. Interviewer quality, viewpoint, attention all factor in, and in about 1/2 the cases, I had a strong vibe from them that they were disinterested in the process/person. I could comment on whether or not I thought their process actually produced superior results or not, and how they would measure. I'll say it is at least a small step up from their previous brain teasers. Hopefully, they will continue to refine their processes.

compumike 8y ago

(Disclosure: I'm an engineer & interviewer at Triplebyte) These false negatives are avoidable with a better-designed screening process. This "exact match" issue is why we use multiple choice questions (pick from 4 choices) for initial technical screening. If you know what you're talking about, the format is far more forgiving to all of the cases described in the post, as you can rule out obviously incorrect answers. If you don't know what you're talking about, your odds of doing well are are stacked against you after a few questions. Once you're doing a video interview with one of our engineers, we know what makes sense, can ask follow-up questions, and if you plausibly know more than we do about a topic, can make a note to look things up or ask our teammates in #interviewers. (Note: we're hiring remote engineers to grow our interview team: https://news.ycombinator.com/item?id=16815444 https://news.ycombinator.com/item?id=16815444 )

tzs 8y ago

> There's an array of 10,000 16-bit values, how do you count the bits most efficiently? I would have said that I would multiply 10000 by 16. Oh well, no Google job for me I suppose.

poxrud 8y ago
I find that the solution to a lot of these trick interview questions is to use a hash table or some kind of a look up table. Even the famous google mock interview video uses a hash table in the solution. The solution to this question is to use a 256bit lookup table. You'd need to precompute the lookup table that will give you the bit count of every possible bit combination in a byte. Then traverse your 10,000 long array, use your lookup table to count the bits and add them to your total.
- tzs 8y ago
  Assuming that they want the number of 1 bits (the question asked for the number of bits, not the number of 1 bits--hence my answer), it is not obvious to me that a lookup table is the fastest. Given an unsigned 32-bit value, v, this well-known bit hack [1] counts the number of 1 bits: v = v - ((v >> 1) & 0x55555555); v = (v & 0x33333333) + ((v >> 2) & 0x33333333); count = ((v + (v >> 4) & 0x0F0F0F0F) * 0x01010101) >> 24; If you can treat the 10000 16-bit values as 5000 32-bit values, applying the above 5000 times might be as fast or faster than applying the table lookup method to 20000 bytes. It will depend on precise details of the particular computer on which it is run. [1] http://graphics.stanford.edu/~seander/bithacks.html http://graphics.stanford.edu/~seander/bithacks.html
- rurban 8y ago
  Nope, hardware is better. Throw popcount at it, in parallel. ispc will help you with the parallel bit if your compiler cannot autovectorize good enough.
zpatel 8y ago
If one was going to be hired to work on cloud API or some enterprise tool, not sure how this low question would qualify someone as a better software engineer.

nimbius 8y ago

ive had 3 google interviews, one on-site, and I can say without a doubt that its not only demoralizing but a complete waste of time. Reading their own outline of the hiring process and watching the youtube video, I was instructed that "goofy" google questions weren't asked anymore. No less than 5 minutes in the meeting room and I was met with "how do you build a datacenter on the moon?" followed by "how many cans of beer can you fit in a school bus?" My latest phone screen about a year ago started off with a technical recruiter handing off from Mountain View to a recruiter in San Diego, then passing me back to a technical screener in mountain view who couldnt remember his questions. The follow-up technical review came from Boulder Colorado and focused on C programming and Linux dynamic libraries for a SRE position. All in all I hope they get their hiring process sorted out. The most disparaging and frustrating thing is hearing "just keep trying! everyone has to apply at least N times before they get hired." The fact that this sentiment exists at all speaks volumes to the management climate.

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

AboutTheWhisles 8y ago

A lot of these were the recruiter having no understanding of what they were asking, but the bit counting is just nonsense. A lookup table requires an extra memory access that by its nature is incoherent. Contrast that to being able to read the memory straight through and having it prefetched, then using the popcnt instruction: https://www.felixcloutier.com/x86/POPCNT.html https://www.felixcloutier.com/x86/POPCNT.html

compumike 8y ago
Accessible as __builtin__popcountll(unsigned long long) in gcc or clang. Especially handy if you're writing a chess bot.
zeusk 8y ago
> A lookup table requires an extra memory access that by its nature is incoherent. Pedantic but, the LUT would also remain in the cache if there wasn't some issue with cacheline contention. Although, I do agree that POPCNT + prefetch and unrolling will do much better.
- AboutTheWhisles 8y ago
  I thought the same thing, although I've tried LUT approaches to other problems like gauss curves and the results were much slower than I expected. The LUT may stay in the L2 cache, but whatever was going on, there was actually a big discrepancy between looking values up and just calculating the gauss curve equation even though it had exponents on floats.

DannyBee 8y ago

So, as part of my job, I have been the hiring manager for directors for Google (3 in the past 6 months), and recruit quite a bit. This was a simple phone screen, and it seems the recruiter was not given a good set of questions. However, I actually doubt it was really a director of engineering screen, despite this person's experience level (maybe it should have been, but ...). I say this because I know a lot of the leadership recruiters, (it's a separate thing from regular SWE/manager recruiting), and I know how the process works. They don't screen candidates this way normally precisely because it doesn't make sense. (Whatever you may think of Google's regular non-leadership recruiting :P) Instead, they ask question directly relevant to what the hiring manager wants/needs (IE i give them the questions to use), and in most cases, do just enough to know whether it would be a waste of time for the hiring manager to talk to them. At which point, a hiring manager like me talks to the candidate and decides whether to bring them in for onsites. This particular set of questions seems closer to standard non-leadership SRE questions.

DannyBee 8y ago
It turns out this post is from 2016 and i already said the exact same thing then: https://news.ycombinator.com/item?id=12701272 https://news.ycombinator.com/item?id=12701272
- dman 8y ago
  DannyBee discovered to be idempotent.
  - juancampa 8y ago
    Functionally pure
fjsolwmv 8y ago
I thought Google hires into a general pool, and hiring managers don't "own" candidates like Amazon HMs do.
- 8y ago

nateburke 8y ago

I had the opportunity to speak with someone who was on the hiring committee at google when the company scaled from ~5k employees to ~20k employees. This was the committee of people in charge of designing the interview funnel though I'm not sure if it was for engineering, specifically, or the whole company. He said that there were two very large compromises that had to be made in order to hit those growth numbers: 1. Near-total reliance on gpa and school prestige for entry-level position initial resume screening 2. Relaxation of membership controls on the internal pool of people at Google qualified to administer the "is googley?" culture fit interview I would not be surprised if "allowing non-technical people to pre-screen technical people" is a similar growth-forward HR compromise made, resulting in the OP's suboptimal experience.

bootloop 8y ago

Interesting. My Google Interview started with 1h interviews with two Software Engineers (who were working on Google AdWords) They asked mostly data structure questions and gave a short exercise which I had to solve. The first engineer had obviously lack of exp and interest in this process, the second one was a lot more pleasant to talk to and I felt a lot more comfortable. (Unrelated to my actual performance which was properly not good enough in any case.)

deleted 8y ago

[deleted]

utopcell 8y ago

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

pfarrell 8y ago

In my experience and from what I've gleaned from the outside, recruiting at Google consists of shoveling as many bodies into the pipeline every week to allow the top few to get picked for an onsite interview where it doesn't matter if they say no to everyone because there are always more applicants next week. After getting through phone interviews and getting flown out to SF for an interview at youtube, I made the mistake of thinking I was like 95% of the way through the process. At google (and I suspect a few of the other megacorporations), getting to onsite interviews means you now in the lottery with similar chances.

qooiii2 8y ago

Google asked if I would do a phone screen a few years ago for an SRE position, and I thought that process was hilarious. In my case the questions had nothing to do with my background (microcontroller firmware for sensors) and it was only by incredible luck that I could answer them. For example, I had just read about some data structure the day before. The recruiter didn't spend much effort telling me what the job was or why I should consider leaving my current great position for it. I said, "no thanks!" when I found out what an SRE actually does. It seems like Google's interview process is designed to measure how much a candidate wants to work at Google. This is probably okay for them, but it's going to result in them overpaying for good people.

nfRfqX5n 8y ago

my interview process spanned 5 months between all of them. really wasn't fun trying to have a convo and answer questions while the interviewer types down every word you say. seemed very robotic. you get almost no feedback for spending all of that time, so you don't really know where you went wrong or how to improve. i understand they can't say anything due to the possibility of a lawsuit, but they should be able to figure something out with that

deleted 8y ago

[deleted]

CodeSheikh 8y ago

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

Molaxx 8y ago

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

oldgun 8y ago

Seen this piece before, still funny to me. > Thought: I guess that's what happens when AI bots discover recreational drugs. That's why engineers should be interviewed by engineers.

LordHumungous 8y ago

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

jroseattle 8y ago

We experienced the same type of issue with my company, and decided to try to address it. First, our problem statement: filtering phone-screens by recruiters is resulting in poor experience, false positives, etc. We thought about potential causes, but instead opted to look at the logistics of the call: recruiter runs process, gets responses, and then returns to engineering with feedback. It was a vacuum filled with innuendo, unspoken assumptions, you name it. Collectively, our recruiting operation was an echo chamber. So we asked if we could have recruiting calls recorded and/or transcribed. Candidates had no problem agreeing to it -- the recruiters were reluctant at first. (You can probably guess where this going...) We recorded/transcribed maybe five calls, and that's all that was necessary. We saw dramatic improvement, and we owe most of that to the Observer Effect. We maintained the same throughput of candidates, but we saw more ideally-suited candidates pass through as well as heard better experiences from candidates. I'd suggest most any operation try this.

jvreagan 8y ago
Love the idea, thanks for this!

trevor-e 8y ago

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

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

ksk 8y ago

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

maxk42 8y ago

This pisses me off so bad: Quicksort does NOT have "the best big-O". It's big-O time complexity is O(n^2). Big-O refers to the worst case time complexity. Quicksort will on average take (n log n) time complexity, but that's not its big-O, that's its big-Theta. Some try to skirt this by saying "if you randomize the order of the data first, it will be sorted in big-O of n log n" but again, that's the average time complexity, not the pathological case. A lot of CS books teach this wrong. Please stop being wrong: O(Quicksort) is O(n^2)

bmcfeeley 8y ago
Big-Theta is not an average case, it is a special form of Big-O and Big-Omega wherein the worst case is also the best case from a complexity perspective. This is sometimes true in sorting since comparison based sorting cannot be improved beyond n*log(n) except in specific cases for specific domains. You are absolutely on the money about worst case being O(n^2) though for quicksort.
- maxk42 8y ago
  I stand corrected. Is there a notation for "average" complexity?
  - bmcfeeley 8y ago
    Not that I'm aware of! As you've seen, I see Big-O abused into shorthand for "on the order of" to the effect of "average case is O(nlog(n))"

lisper 8y ago

My Google phone screen circa 2013 went something like this: for (i=0; i<NUM_QUESTIONS; i++) { Interviewer: [Technical question] Me: [Answer] Interviewer: That's right! } Followed by: Interviewer: You do understand that the position you have applied for is a managerial position, and that you're going to be dealing with schedules and budgets and not anything technical. Is that really what you want to do with your life? Me: Um, no, not really. Interviewer: OK, well, have a nice day then. Good bye.

ScottBurson 8y ago
?? But you had worked there before, right? Didn't they remember you?
- lisper 8y ago
  > you had worked there before, right? Yep. :-) > Didn't they remember you? If they did, they hid it well.

booleandilemma 8y ago

It’s obvious from this interview that Google is looking to hire a robot. If they were looking for a human they would have used a captcha.

urda 8y ago

I'll repost this again: https://news.ycombinator.com/item?id=12701858 https://news.ycombinator.com/item?id=12701858 This is a bullshit article, why did it frontpage again ?

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

jason_slack 8y ago

One of my interview questions: Interviewer: What is the difference between a mutable and immutable string? Me: A mutable string can be changed. A immutable string cannot be changed. Interviewer: Nope, think mutations. Mutable string can be mutated. Me: Mutated? Altering DNA? Interviewer: If you don't know this there isn't any sense in asking more difficult questions. Me: Floored.

mirceal 8y ago
follow up: do you know that everyone is a mutant?
- jason_slack 8y ago
  Sadly when she said mutation I thought about the Teenage Mutant Ninja Turtles :-)
itronitron 8y ago
I hope you didn't list String expertise as one of your technical skills.
- jason_slack 8y ago
  Explain?
  - itronitron 8y ago
    It is a joke, as so many interviewers complain that people lie about their technical skills and experience, if you listed String as a technical skill and the interviewer thought you didn't know what a mutable String was then they would conclude that you lied about your skill set. Hopefully you can see the humor. I feel your pain so can understand why you might not think it is funny.
    - jason_slack 8y ago
      I thought it was a joke but then I talked myself out of it :-) Yeah interviews have been rough this time around. Before this I hadn’t interviewed in 10 years.

throwaway84742 8y ago

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

axaxs 8y ago

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

icedchai 8y ago

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

s2g 8y ago

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

rurban 8y ago

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