This was posted previously, in October 2016:<p><a href="https://news.ycombinator.com/item?id=12701272" rel="nofollow">https://news.ycombinator.com/item?id=12701272</a><p>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).<p>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 (<a href="http://www.gwan.com/about" rel="nofollow">http://www.gwan.com/about</a>), qualifies him for a director-of-engineering-level position. He's probably being interviewed for an SRE team lead or thereabouts."<p>Also, a ton of this conversation makes a lot more sense if you make the assumption that the interviewee is misremembering the questions: <a href="https://news.ycombinator.com/item?id=12702726" rel="nofollow">https://news.ycombinator.com/item?id=12702726</a> (Which is a very gentle assumption, if the interviewee also mistakenly thought they were being interviewed to be a director of engineering.)<p>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 <i>exactly what this process is supposed to do.</i>
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.<p>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.
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.<p>This was a simple phone screen, and it seems the recruiter was not given a good set of questions.<p>However, I actually doubt it was really a director of engineering screen, despite this person's experience level (maybe it should have been, but ...).<p>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)<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.<p>This particular set of questions seems closer to standard non-leadership SRE questions.
> Recruiter: that's not the answer I have on my sheet of paper.<p>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.<p>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>
Google hiring has been fubar for years now.<p>I think many of us here have been contacted ( unsolicited ) by Google for job interviews in the past.<p>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.<p>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...
We experienced the same type of issue with my company, and decided to try to address it.<p>First, our problem statement: filtering phone-screens by recruiters is resulting in poor experience, false positives, etc.<p>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.<p>It was a vacuum filled with innuendo, unspoken assumptions, you name it. Collectively, our recruiting operation was an echo chamber.<p>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...)<p>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.<p>I'd suggest most any operation try this.
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.
One of my interview questions:<p>Interviewer: What is the difference between a mutable and immutable string?<p>Me: A mutable string can be changed. A immutable string cannot be changed.<p>Interviewer: Nope, think mutations. Mutable string can be mutated.<p>Me: Mutated? Altering DNA?<p>Interviewer: If you don't know this there isn't any sense in asking more difficult questions.<p>Me: Floored.
> Recruiter: that's not the answer I have on my sheet of paper.<p>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.<p>> 7. what is the name of the KILL signal?<p>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.
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.)<p>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.
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?"<p>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.<p>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.
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.<p>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.<p>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.
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.
What that list should really have in it is:<p>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.
My Google phone screen circa 2013 went something like this:<p><pre><code> for (i=0; i<NUM_QUESTIONS; i++) {
Interviewer: [Technical question]
Me: [Answer]
Interviewer: That's right!
}
</code></pre>
Followed by:<p>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?<p>Me: Um, no, not really.<p>Interviewer: OK, well, have a nice day then. Good bye.
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.<p>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".
Plenty of discussion on the first time this was posted:<p><a href="https://news.ycombinator.com/item?id=12701272" rel="nofollow">https://news.ycombinator.com/item?id=12701272</a>
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.<p>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.<p>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.
What an absurd test.<p>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?
Whatever you are about to say was likely covered in the existing 1000-comment thread <a href="https://news.ycombinator.com/item?id=12701272" rel="nofollow">https://news.ycombinator.com/item?id=12701272</a>
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.<p>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.
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?<p>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.
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.
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.<p>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.<p>I don't know if this is due to changes in the past 5 years or the recruiters being from different teams.
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.
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.<p>He said that there were two very large compromises that had to be made in order to hit those growth numbers:<p>1. Near-total reliance on gpa and school prestige for entry-level position initial resume screening<p>2. Relaxation of membership controls on the internal pool of people at Google qualified to administer the "is googley?" culture fit interview<p>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.
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.<p>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.<p>Hopefully, they will continue to refine their processes.
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.
> There's an array of 10,000 16-bit values, how do you count the bits most efficiently?<p>I would have said that I would multiply 10000 by 16. Oh well, no Google job for me I suppose.
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.<p>Contrast that to being able to read the memory straight through and having it prefetched, then using the popcnt instruction:<p><a href="https://www.felixcloutier.com/x86/POPCNT.html" rel="nofollow">https://www.felixcloutier.com/x86/POPCNT.html</a>
(Disclosure: I'm an engineer & interviewer at Triplebyte)<p>These false negatives are avoidable with a better-designed screening process.<p>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.<p>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.<p>(Note: we're hiring remote engineers to grow our interview team: <a href="https://news.ycombinator.com/item?id=16815444" rel="nofollow">https://news.ycombinator.com/item?id=16815444</a> )
> Me: on which kind of CPU? Why not let me compare my code to yours in a benchmark?<p>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.<p>In practice this recruiter might be bad at their job by binding themselves so rigidly to the script.
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?
This pisses me off so bad:<p>Quicksort does NOT have "the best big-O". It's big-O time complexity is O(n^2). Big-O refers to the <i>worst case</i> time complexity. Quicksort will on <i>average</i> 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 <i>average</i> time complexity, not the pathological case.<p>A lot of CS books teach this wrong. Please stop being wrong: O(Quicksort) is O(n^2)
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.<p>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
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.<p>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.)
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.
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.
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?
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"<p>But of course they wouldn't implement it in such a way.
I'll repost this again: <a href="https://news.ycombinator.com/item?id=12701858" rel="nofollow">https://news.ycombinator.com/item?id=12701858</a><p>This is a bullshit article, why did it frontpage <i>again</i> ?
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.
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.
Seen this piece before, still funny to me.<p>> Thought: I guess that's what happens when AI bots discover recreational drugs.<p>That's why engineers should be interviewed by engineers.
This again? <a href="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" rel="nofollow">https://hn.algolia.com/?query=Google%27s%20%E2%80%9CDirector...</a>
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.
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...