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), 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 (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.
> 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.
> incorrect/inflexible quizzing about tech questions is inappropriate full stop
I don't disagree with this, but (to the best of my memory - this was in 2011), when this initial phone screen was presented to me, it was presented with some amount of "We want to figure out what you're good at so we're having the right people interview you for the right roles." Which is to say, I suspect that him failing out halfway through this screen was because of combativeness / personality, not phone screen performance per se.
> You can't ensure that there will be no hurt feelings ever, but ideally the candidates you fail don't go around talking about how poor your interview process is.
I think I disagree with this though - there are certain people who are going to be predisposed to complaining about things that don't go their way, and you want to make sure you fail them as early as possible. At a company small enough that its strength is the CEO's coding abilities, a curmudgeon with significant raw technical talent can do very well. At a Google-sized company they just can't.
The OP is misremembering (slightly) some questions.
Also, this quiz is given by non-technical recruiters just to get a guage on how tech-savvy the candidate is. If I remember correctly, the passmark is 6/10.
The questions (when not misremembered) are very precise in their wording, and recruiters are given a pretty comprehensive list of correct answers.
I'm sure a few great candidates fail this stage, but that's the nature of hiring. Google gets a lot of job applications per day, and a first stage screening like this needs to be able to be executed by non-technical staff in a few minutes. Other companies use online tests, which tend to take the candidate more time and are easier to cheat at.
They can, actually...the culture needs to learn to adopt them is all.
Having real talent and having to basically navigate terrain of those with less skill than you and yet, oddly enough, more power, is very frustrating. These people can knock orders of magnitude off development cycles, and make subtle decisions that affect your product years in to the future.
If anyone feels even remotely insecure because of your prowess you are shot down. I was pushed out of Microsoft just for accomplishing a task that was supposed to be impossible "because a senior engineer said so." In other words, I did my job (I wasn't aware it was supposedly impossible) and then a management chain became incredibly uncomfortable and dumped me.
You might say I'm the problem...I point to the stack of clowns that said it couldn't be done and go...yeah sure.
> These people can knock orders of magnitude off development cycles, and make subtle decisions that affect your product years in to the future.
These people can also introduce orders of magnitude into development cycles, and make subtle decisions that affect the product in negative ways years into the future. I seem to have made a career out of cleaning up after these people, and I have no sympathy for them. An amazing research project or tech demo isn't an amazing sustainable project.
> I was pushed out of Microsoft just for accomplishing a task that was supposed to be impossible "because a senior engineer said so." In other words, I did my job (I wasn't aware it was supposedly impossible) and then a management chain became incredibly uncomfortable and dumped me.
When I've seen this, it's usually because the task can be done 90% in a straightforward way but 100% is impossible, and the person doing the task thinks that doing it 90% counts, possibly because they're unaware of how important the the remaining 10% is, and no amount of explanation will convince them they're seeing the problem wrong. Then they should be let go, not because they did the task, but because they're unable to understand requirements and wasting both the time of others and their own time.
... all that said, there's a very good place for this type of person: small businesses. That seems to be where the author of this article is, right now. He's got some weird ideas about how computers work, that are probably not right, but maybe they are right and he's a genius and we're all years behind him. He's built a product around those ideas. If he can sell the product, more power to him. If he can't, and the product is meeting 90% but not 100% of his customers' requirements, they just don't buy and go to a competitor. No awkward conversations about firing, no wasted time trying to get their existing hire to perform instead of hiring people who can do the job, etc. And the burden of getting him to learn how to understand requirements is entirely on him and not on anyone else.
I don't think there was any problem with the applicants attitude, but plenty wrong with the screener's attitude. As in, I wouldn't want to work for an arrogant prat like that.
> 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 kinds of defeat the purpose of the screening interview though doesn't it?
The point is to not disturb an engineer when 99% of the people that are being screened are unqualified.
To be fair we are talking about Google, not the local shop at the corner of the streets. Each recruiter must do tens of screening a day, and they have tens of recruiters assigned to each department, we are not talking about reviewing 2 applications a day during coffee break.
> 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.
I would not ask the questions listed in this interview. But, I'm not a recruiter. I think it's safe to say that the average recruiter has a better understanding of their objectives and constraints than I do, and is better able to judge what types of questions to ask during an initial screen than I am. Those questions may not be optimize for the same thing any given candidate is optimizing for.
> 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.
People in the original thread in 2016 said much the same, arguing that people would no longer want to work for Google. It's 2018 and Google is still not having any trouble attracting engineering talent. Seems like offering high salaries and interesting work matters a lot more to the average candidate than whether the prescreen has a view suboptimal questions.
> I think it's safe to say that the average recruiter has a better understanding of their objectives and constraints than I do, and is better able to judge what types of questions to ask during an initial screen than I am.
That's an odd assumption to make, that the average recruiter is competent, for a community that assumes the vast majority of their fellow engineers can't code.
> a community that assumes the vast majority of their fellow engineers can't code.
If you're talking about FizzBuzz, that's about candidates, not stably employed folks. Candidates are by definition a pool that favors people that haven't been hired already, except for people new to the industry. https://www.joelonsoftware.com/2005/01/27/news-58/
(Also, there's no rigorous evidence supporting the hypothesis that most people in the industry or even most applicants can't write FizzBuzz, as far as I know. But that's not quite relevant to your question about perception; I do admit there is a perception that the hypothesis is true.)
I never assume the recruiter understands the objectives of a job. All they have to go on is a list of job requirements written as a wish list by the hiring manager, they are seldom technical, and are usually less competent than you average engineer, especially about technical matters.
Good technical recruiters are rare, and seldom work for big companies like Google, Facebook, Amazon, Cisco, (Yahoo), IBM, etc. Most of them read questions from a script, and then believe that the map is the territory.
An annoying interview process is a one-time pain, though. Once you're in it's behind you. (For my current employer - not Google - I did a 3-hour auto-graded coding test in which I resorted to rewriting something in C and not calling free() to make it fast enough to pass all the test cases, which I hated, but it was a one-time thing and the company itself is otherwise pretty reasonable. I should probably have held it against the company, but I didn't.)
If Google is losing out on good candidates, it's going to be either because of false negatives in the interview process, or ongoing engineering culture concerns (which is roughly why I declined the Google offer I got last year), not because of people self-selecting against annoying interviewing processes. Even this blog post itself is written in the form of "Here's what you need to know to get past the process" - i.e., even this guy assumes people still want to work at Google and work around their process.
You forgot one more thing, google is loosing enginers due to it creepy nature. I was invited to interviews on multiple occasions but they are one of the last companies I would work for. I don't care about money, wherever I was working, I had it more than enough to have a really good life and a thousand $ up or down doesnt make much of a difference. But working for a company that actually engages into global spying of people is like a mental prostitution. Not I only wouldn't work for them but also wouldn't take anyone working for them in past working for me. I value people opinion about their impact to the world and google guys went way off into wrong direction. They are simply emitting the signal "I would do anything for money" and this attitude can be understood for someone working in McDonalds, but for a hi-tech worker that can get job anywhere, this is just unacceptable. It shows moral rottening (or just beeing "simpleminded") and... well sorry, there is more than enough other people I will be far more happy to work with. I am really sorry that people like Rob Pike and Ken Thompson, which I highly respect, work for them. As developers (Not Google, not Facebook, not Apple, not Microsoft! The Developers! Without them, they aren't worth a dime!) we are at the moment rulling the world, we have to accept some moral obligations instead of just beeing slaves to making money for others stock options.
(How cool, I get multiple downvotes which means that the average non-important people (I could use stronger words, but you do know where you fit) don't agree, which makes me flattered. Thank you.)
(The other guys upvoting me, thank you, you are somehow restoring my faith, that not everyone is a zealot)
To me, it feels like the Facebooks and Googles of the industry (by which I encompass other ad tech firms) are the 'banks' of 10 years ago. A few years ago, and I bet still today, there were/are a lot of new grads and experienced techies saying openly that they'd not want to work for a bank. Hopefully a similar spurning happens here.
Yeah, I lumped that under "engineering culture," but AMP in particular and the nonchalance about centralizing everything on Google servers—and the fact that I knew AMP's PM would be rewarded for the project's success and not questioned on long-term good of the world in his promo meeting—was a concrete reason I wasn't excited about the job. I didn't want to be subject to the same incentives.
You a G! My sentiments exactly. We are at a critical point in our world where we are the "magicians" and just chasing a paycheck isn't good enough. Interesting work isn't good enough. Making a positive impact on the world is the bare minimum....
I know multiple people who have told Google recruiters that they are not interested on the basis of their famously drawn out and disrespectful interviewing.
Of course, Google is one of the top names in tech and has already employed some luminaries many developers would love to work with, so I'm sure that they get some leaway to treat their interviewees poorly, but for people with other good options, there's not a lot of appeal to being sucked into one end of a very long, very painful funnel.
Having said that, Lazlo Bock has some interesting things to say about hiring in an organisation like Google.
An average IC5 eng at Google makes $350k all in. An IC6 eng goes to around $500k. You dont get those types of salaries elsewhere easily. This is especially important if you have a family in the bay area given the expenses.
It doesn't. That said, in companies like Google, an eng has a lot of flexibility to choose the team they want to work on - so eventually many people find the thing which they really like. And good money on top of it is the icing on the cake.
Also, I linked money since the parent comment talked about finding interesting ans similar paying role as Google's.
Correct, but you can accept/decline the offer based on team placement. You don't have to accept and then see what your options are.
(For complicated reasons I actually spent about May through July of last summer with an offer open, and talked to 5 or 6 different teams through that process... and at the end of the process when I called to decline, I was told that headcount had shifted for Q3, the team I'd most recently spoken to had lost their open headcount, but there were other teams that had now had open headcount and might be interested in talking.)
Many of which have the same type of interview processes?
Hell, Facebook sometimes asks two coding questions per interview round, which is 45 minutes long as I recall. They seem to expect perfectly compiling code.
If you're not doing coding competitions or practicing on Leetcode or other sites of its ilk, where you learn to regurgitate a Knapsack problem solution or Russian nesting doll problem in ~15 minutes, you're going to have a hard time getting into many of the big tech companies unless you went to a university that teaches using this style.
I've seen the sort of problem that required dynamic programing combined with a binary search for the algorithmically optimal solution in a phone screen!
I lucked into an easier interview loop, crushed it, and got hired and performed well at one of these types of big companies.
But I dread jumping ships because of this daunting interview hoop we jump through.
I've already tried to leave and got smacked around in the two interviews I went through because of nerves. I knew the problems, I knew how to solve them, but for some reason I just didn't perform well and couldn't really cross the finish line.
I do lots of interviews of smart, well spoken people who seem to be able to decompose problems, enumerate pros and cons of various solutions and then struggle with a filter and a reduction over the lines in a file.
These people are un-prepared for the interview, this question is easy and not insulting. Anyone doing tech interviews of any sort should be able to answer it, yet most don't.
I suggest two things, 1) start doing competitive coding exercises, there are lots of problem sets available, search for "online judge" [0] and 2) practice interviewing under real conditions, use pramp [1].
Being able to ace a top-k company interview is an ego boost that reduces stress levels day to day.
> I suggest two things, 1) start doing competitive coding exercises, there are lots of problem sets available, search for "online judge" [0] and 2) practice interviewing under real conditions, use pramp [1].
Leetcode, SPOJ, and others are how I landed my current job. What was most helpful for me was actually going back and reimplementing all of the fundamental datastructures and algorithms. E.g. binary search tree, skip lists, BFS, DFS, different sorting algorithms, etc. From then, it was also helpful to remember where these were being used in the real systems I interact with.
Solving the interview problems is typically not my problem. In every round of my Google and Facebook interviews, I knew the optimal solution--confirmed by looking up the solutions after the interview. However, I happened to choke under the interview pressure and turned into a fool. Test anxiety--interview anxiety in this case--is a real thing.
What I am going to do in the next round of interviews is apply for dozens of companies I just don't care about, fail a bunch of interviews to get used to the pressure again, and then re-apply to the companies I actually care about.
Yes, Google is missing out on some top-end candidates, who probably wouldn’t be happy there anyway. It’s not so simple as having a less annoying interview process and getting better engineers. The interview process is an extension of the corporate culture. It embodies certain attitudes and probably attracts certain personalities and repels others. Lots of people want to work at Google, and lots of people do, so only Google knows if something about the process is not working for them.
I’ve worked at Google, and engaged with Google recruiters over the years (who didn’t even know I was an ex-Googler). Talking to their recruiters does feel like talking to chatbots and can feel quite dehumanizing, in big and small ways. I’ve also worked at small start-ups that did world-class recruiting, or at least several classes better than Google — perhaps there are even higher classes, who knows. Both activities are called “recruiting” but they barely seem like the same
thing.
Assuming he didnt lie about the exchange of words, this guy could be a homeless person make believing hes getting hired as ceo of google and this interview would still be an affront to proper advancement. You cannot possibly justify making a quiz that asks about kill in unix and doesnt accept SIGKILL ~literally kill with SIGTERM the default. If you are looking for the default level (15) you should specify. If this interview actually happened the way this guy says it did, Google is making terrible mistakes. I know first semester 2 year networking degree students that would have scored higher than this guy. Seriously people should be appalled at the inadequacy of that interview. Respect lost.
I had a phone screen recently, and got asked some of the questions on this post. However, rather than that sigterm question, I got "What signal does the linux kill command emit by default?", (with the answer obviously being sigterm (I totally blanked out and got it wrong though :P)).
Anyway, I strongly suspect they're just misremembering that question.
> Assuming he didnt lie about the exchange of words
If it's not clear: I strongly believe he lied. (I don't think he intentionally lied, as in deliberately twisted what the interviewer said to make them look bad: I think he genuinely misheard the questions because understanding questions accurately when asked by someone he considers inferior is not his strength, and then incorrectly reported them, which is still lying.)
There are lots of people on the internet (including in the prior thread, including my own memory in the prior thread which I have now completely forgotten) who have reported that the kill question is about default kill command signal and not SIGKILL. It's certainly theoretically possible that the interviewer mis-spoke, but it's very hard to make that sort of mistake if you don't understand the questions you're asking (which is what he's alleging) because you wouldn't know enough to coherently phrase that version of the question.
I've conversed with you before on this website - you are also someone who does not understand technical terms used by other people, and should fail at this stage.
It sucks, but the purpose of an interview process is not to accept everyone, and the fact that certain people (even certain technically skilled people) are rejected is not an indication by itself that the process is broken.
You are saying that when enough people repeat wrong facts it will become true. It certainly happens, but it's still wrong. Many people believe they can turn lead into gold. Just repeat it all over.
>Also, a ton of this conversation makes a lot more sense if you make the assumption that the interviewee is misremembering the questions
But (per [1]) then what would be the charitable mis-remembering of the recruiter saying "that's not the answer I have on my sheet of paper." If it were someone technically competent, that would never be the response; it would be a technical explanation of the error. The most likely scenario is that a non-technical person is being expected to gauge technical answers.
Incidentally, someone on that thread [2] suggested making a meme of that, where the interviewer regards an answer as wrong, despite being very good, because it's "not what they have".
Example from my experience:
Interviewer: "What would be the run time if you did it this way [explanation]."
Me: "Oh, wow, that's a pretty clever approach! In that case, it wouldn't even depend on the input size. Then it would only be limited by IO."
> The most likely scenario is that a non-technical person is being expected to gauge technical answers.
I'm not disagreeing with this - this certainly appears to be the case.
But I think a qualified technical person should be able to understand the question that the non-technical person is asking and respond in a useful way. Although, yes, if they immediately respond with "Wrong, it's <keyword>", it's hard to do that. But I feel like a good interviewer (good is orthogonal to technical!) is likely to say "OK, so what is the runtime?", and "constant" and "O(1)" should both be on their list of keywords.
My charitable mis-remembering would be that the transcript here skipped these sorts of prompts, or that the interviewer was actually upset at the interviewee's demeanor/attitude already and wanted to cut the interview short by that point and was just trying to finish their block of questions. (Which I think is legitimate. As a technical interviewer, if you start condescending to me during the interview, I'm much less likely to give you the benefit of the doubt and help you along with Socratic hints.)
"As a technical interviewer, if you start condescending to me during the interview, I'm much less likely to give you the benefit of the doubt and help you along with Socratic hints."
As a technical interviewee, if a screener acts like all they are there for is to prove that they are smarter than me and start condescending to me, I'm not going to give a damn about their questions because I wouldn't want to work with them.
When a technical question has more than one answer, (like binary, decimal or mnemonic values for changing file permissions), the screener has to know that, or they make fools out of themselves. The whole thing with "attributes" vs "metadata" was just stupid. (Technically the metadata is comprised of the attributes. So they are both correct.)
>But I feel like a good interviewer (good is orthogonal to technical!) is likely to say "OK, so what is the runtime?", and "constant" and "O(1)" should both be on their list of keywords.
In that case, he was the CTO, though, and should know that "constant" is the same as "does not depend on the input size". (Though I'll admit I could have been unclear by trying to pre-emptively show how I knew what the next binding constraint would be.)
Agree with your points otherwise, but I still think the protocol should be (even if you're skipping through), to say something more like "let me note that down and I'll pass on your response" rather than imply it's not wrong because it's not in your list.
>Also, a ton of this conversation makes a lot more sense if you make the assumption that the interviewee is misremembering the questions. Which is a very gentle assumption.
No, that's a pretty insulting and disturbingly koolaid flavored presumption.
This conversation makes sense to me because of the number of people who have commented that they ended up being unwittingly considered for position that they did not apply for and did not actually even necessarily want. There's at least two in the comments section here and I know two more personally (one of whom is a very talented director of HR, ironically enough).
I actually even said this to that director of engineering's comment you mentioned two years ago.
I admit that this is certainly possible (Google recruiters wildly underleveling people, at least relative to their expectations if not their actual qualifications, and not clarifying this before passing the candidate onto other recruiters).
If it's happening, it's a very different problem (no less real of a problem, though) and process fixes at this stage wouldn't help.
Also, this interview performance should have been enough to disqualify this candidate for the role he envisioned, too. If only because, if he was actually intending on applying to be a director of engineering, the right answer to question 3 is something like "I think there's been some sort of mistake."
It's not only possible it's likely if they are setting general hiring quotas for their recruiters.
And, they almost certainly are setting quotas because they're currently being sued by one of their own recruiters over their quota policy.
>Also, this interview performance should have been enough to disqualify this candidate
They neither qualify him nor disqualify him. Correctly or near correctly answered trivia questions tell you almost nothing about a candidate other than that they're probably a software engineer of some kind.
> They neither qualify him nor disqualify him. Correctly or near correctly answered trivia questions tell you almost nothing about a candidate other than that they're probably a software engineer of some kind.
Please read the entire sentence you quoted halfway - by "interview performance" I don't mean the correctness of the answers, I mean his a) expectation that UNIX trivia quizzes are a normal part of a director-level interview (and that it's not more likely that there was a miscommunication in scheduling) and b) attitude.
"Correctly or near correctly answered trivia questions tell you almost nothing about a candidate other than that they're probably a software engineer of some kind."
This. I hate trivia, and trivia questions. You can get a book or find a website to bone up on trivia questions if that's your thing. However, it says nothing about whether you actually know anything about working with computers every day.
Ha! I remember this from back then. Interview process aside, did you see the guy's technology page?
Which process has led to TrustLeap's technology? Instead of trying to add something on the top of a multi-layered construction done by many different persons in a period of time exceeding 30 years, TWD has resolved the problem from scratch in a few months.
> TrustLeap, the security division of TWD Industries AG (founded in 1998), protects digital assets with cryptanalytically unbreakable technology (safe against unlimited computing power as it is proven mathematically that no key leaks can be exploited).
At some point an inflated sense of experience is necessary to succeed in starting your own company. You have to literally believe you are capable of having a real impact. Jeff Bezos, Elon Musk, Bill Gates, etc. All were told at one point "you don't have the necessary experience for that." Or "are you fucking crazy?" Or something meant to challenge their experience. The hard realization is that none of them had the experience...but boy did they sure earn it.
Point is: arrogance isn't the curse you might think it is.
There are a handful of sociopathic people who reach those heights, while most of the rest do not. Mistaking arrogance for an active ingredient in success is probably a mistake likely to lead you down a bad road. Ruthlessness, arrogance, greed might be things you need to be a high level founder, banker, CEO or politician, but most people with those traits are abject failures. You need to be smart, and very lucky as well, and even without arrogance smart and lucky should pay off.
Whereas I think the screener had an overinflated sense of both his knowledge, importance and the "rightness" of the answers that he expected. The questions were narrow, and the right/wrong on the answers was oversimplistic and more suited to a freshman computing college test, not the working world. The guy answered him with more nuance and detail, but he arrogantly told the guy to "learn more about...", when it's pretty obvious that the appicant knew more than the screener.
> 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.
This is obviously an excuse for how shitty the interviewer is. If you want to rule out people with a inflated sense of their own experience, the way you do that does NOT involve telling them they're wrong when they're obviously right ("that's not the answer I have on my sheet of paper").
Again, my claim is the interviewer did not say exactly that and this man with an inflated sense of his own qualifications is retelling the story in a way that's favorable to him.
All available evidence points to him either mishearing or mis-transcribing the question, which was actually "What is the signal sent by the kill command."
As I and others have said a few times on this thread and on 2016's thread, there are a huge number of sources of people saying "I got the same question" and "The question was 'What is the signal sent by the kill command.'"
So there are two possibilities:
1. This particular interviewer actually said "What is the name of the KILL signal," despite other interviewers regularly saying the question correctly. The entire thesis of this article is that the interviewer does not understand UNIX and is reading pre-written questions from a piece of paper, so that's an extremely unlikely mistake for the interviewer to make.
I do. I've interviewed twice and gotten offers twice (and declined twice). That's what I said in my post. I'm claiming no greater (but no less) knowledge than having gone through the interview process.
Are you implying that because you went through a couple of good interviews with them, and because one director who works at Google said that they don't hire this way, it doesn't happen?
That's the worst logic ever.
I'm blaming Google for doing this, and you take it to imply that I said you work at Google? Maybe you didn't accept those offers from Google. It still doesn't mean those things didn't happen at Google - and it is extremely shameful that you resort to defending them.
Congratulations, what you have done is just free PR for Google. I'd rather listen to everyone else than you.
Not sure why this is so highly rated when it's so blatantly wrong. There are literally dozens of director-level interview samples online (as well as people discussing these on Quora and other platforms) and they all start with the recruiter screening process. To say that only SREs get screened is incredibly misleading.
To be perfectly honest, I doubt there are dozens of director-level interview samples because there aren't tons of engineering directors, further "director of engineering" is a management, not technical role, so wouldn't be given questions like this, at all, and of the remainder, most of them were promoted from within google, not hired from outside it.
Most new hires get screened in some manner, but very few new hires are directors of engineering, so I'd mighty curious to see your source for the interview questions they got.
What these questions are are the standard set of pre-screening questions asked of a potential SRE IC or maybe TLM candidate. A SWE wouldn't be asked these questions, because they aren't related to the role. A SWE candidate still might get screened, but not with these questions.
> What these questions are are the standard set of pre-screening questions asked of a potential SRE IC or maybe TLM candidate. A SWE wouldn't be asked these questions, because they aren't related to the role. A SWE candidate still might get screened, but not with these questions.
A question on Glassdoor (for a Director position) is in the same vein: "How do you tell if a calculator is 8 bit or 16 bit."[1]
> How do you tell if a calculator is 8 bit or 16 bit.
As someone who has reverse-engineered calculators, that question has me curious. You could implement the same external behavior regardless of what processor a calculator uses. So I can't see any way to determine the bit width. Is there an answer I'm missing? (Also the question ignores the many 4-bit calculators.)
(Of course you could open up the chip and take a look with a microscope, which I've done. But I don't think that's the answer they are looking for.)
b) That's a different question from this set about UNIX arcana, so it's not the same set
c) All of the other questions on that page are non-technical, so this isn't a question from a standard director set either. (It may be what 'DannyBee said, that people assumed they were being screened for a much higher position than they were actually being screened for.)
Can you post a link to one of these? The first Quora answer I find says, "First interview was on the phone with a recruiter. The questions were typical recruiter screening. Nothing hard or detailed. Questions about background and feeling out my interest."
I definitely believe there's a recruiter screening process - I would just be surprised if it's the same screening process they give to new college grads, with the same slate of questions. (Even if you're going to give them technical questions, at least give them harder technical questions!) I obviously have no real information having not interviewed for a director-level position, I'm just stating that these questions seem like the same slate I got as a college grad.
I read a similar screen a few years ago (some guy with a math PhD, also applying for a director position at GOOG). I'll try to find the blog post. Even if the screens are different, I'm not sure they're that different.
Any luck finding this? You claimed there are dozens of director-level interview samples online with questions similar to this story, and all you've posted is that one person on Glassdoor got one technical question that wasn't anything like the ones in this story.
I suspect, again, it's more people thinking they are being interviewed for director, when they aren't (or it was long enough ago that it was before leadership recruiting existed)
Doesn’t sound like the interviewee has an inflated sense of worth from what’s written and it sounds like the interviewer cheated off someone to get his degree
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.
My take on Google's hiring process, having observed a few people going through it, is that it's a complete nightmare. Unfortunately I don't think there's any incentive for them to change because so many people are willing to go through that nightmare in order to work there.
My whole approach to recruitment is to strip the process down as much as possible to make it as easy and appealing as possible for people to apply, but that's because I have to: I work for a company nobody's heard of, and which doesn't have engineers queuing up to work for them.
In my experience, the recruiters are some of the best, nicest folks I've had the pleasure of dealing with. I know that's a low bar to crawl over in the world of copy-paste recruiters, but they were good folks who made sure things worked, and when my interviewer failed to call, made sure to prod his ass.
Now, I didn't get past the phone screen but the experience actually interviewing was so piss-poor I doubt I'd have pressed on had I passed. The interviewer managed to call nearly 30 minutes late, spent about as much time talking about himself as he did asking me questions, and when he actually asked questions he would proceed to repeat what I had said as if I hadn't even said anything.
This sounds like “Our engineering director was very impressed with your experience, and we would like to set up a 15 min call to find out what you actually do.” Pretty much a recruiter tactic.
They discover some random nugget of info about you and then they use it as a lead to cold email you. If you respond, they apply for an entry level position on your behalf.
Sounds like you ate the recruiter linkedin spam bait, or whatever the thing was then. "We are very impressed with your $EXPERIENCE and our engineers would like to talk to you."
> It would seem Google HR / Recruiting hasn't improved in all these years.
I agree that your experience in 2003 was terrible, but to draw this conclusion from the article is extremely presumptuous. There are lots of well-intentioned people working in recruiting at Google, and you are suggesting that none of them have made any improvement in the process in 15 years?
> three calls with gate-keepers of sorts, between which there was zero knowledge transfer from call to call
That may have been disorganization, but there's also a decent justification for intentionally limiting knowledge transfer. You get 3 independent opinions that are not biased by the others.
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
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"?
Because reading someone else's proprietary code exposes the company potentially to liability? Not just claims of IP theft, but there would have to be legal vetting that you have the right to show that code in the first place. Also, I have no way to confirm how much of the code you wrote yourself.
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.
>This particular set of questions seems closer to standard non-leadership SRE questions.
OK, you've established your credentials, and cast a bit of doubt on the accuracy of everything in the linked post by pointing out a likley inaccuracy about the actual position.
But at no point do you claim that the phone screen didn't actually go like that. Nor do you offer defense of a call that did go like that.
And isn't that the part of the post that really matters? If that retelling of the call is even 30% true, Google flubbed it. Hard.
The important part is that if this person believed they were being interviewed for a director-level position, and if they actually got new-college-grad-level questions, then something else has gone very wrong already. Either Google flubbed hard well before the interview even started, or this person isn't capable of understanding things that Google recruiters are saying to them, at which point their entire retelling is suspect.
I was approached by some Google recruiter for a very specific engineering management role based on my background. I also thought the same about that general pool thing before that.
The process seemed quite different from what I've read here about the Google software engineer recruitment process.
(After a few phone calls/interviews I realized this was not a position I would likely enjoy, all things considered, so I told them I thought I was bad fit because of A and B, but please keep me in mind if you have another opening that's more suitable.)
> 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>
>the process gets abstracted into whatever Google thinks can be done algorithmically
Unfortunately, this is not unique to Google. Believing that all the world's problems and challenges can be solved by an algorithm is part of the culture. And it's what alienates SV from the rest of the world.
It's why Facebook doesn't understand that people want to see what they choose to follow on their newsfeed, and not what FB's latest algo thinks they want to see.
It's why Google thinks it's OK to collect every scrap of data it can about a person and try to follow them around. If a person did that, it would be called "stalking" and is a crime.
It's why Uber believes that it's OK to treat its passengers poorly and its drivers even worse - because they're all just values in a seemingly unlimited array that can just be popped off if they don't meet the metric.
It's why Amazon thinks it's OK to mix fake items in with real items when shipping purchases. Because data can always be trusted and 1 always equals 1.
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...
A friend of mine got into a little confusion at immigration when asked his profession to which he replied “programmer”, which was seen as lesser category of job than his visa was issued for, which was “software engineer”
Hah, that happened to me at the Canadian border. When asked what my profession was, I said "Computer Programmer", but my visa was issued for an "Architect". Had fun explaining that I am a "Software" Architect, not a building architect.
>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.
Worth noting that for specialist roles and middle/senior management, there are special pipelines. The problems seems to be a mismatch in what the average person thinks is "specialist" and what Google thinks is specialist. Lots of people think they're specialists, maybe they are, maybe they aren't, but more often than not it doesn't matter anyway. "I built an app" or "I built a tool used by many of your engineers" or whatever doesn't make you a specialist. It might be a reason to stick you into the generalist SWE pipeline, and it might be a 20% project for you
There's a surprisingly high hit rate for "checking random notable person in the OSS community in the company directory". They almost never work on things related to their public notoriety.
The one exception to this is research staff. Someone notable for their research is probably hired for their research. But this doesn't mean that any PhD will be hired for their research, much as you won't be extending your thesis if you get hired by a quant trading firm.
>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.
This is perhaps the single most important aspect of the hiring process at the bigCos. The hiring process is built from the ground up to prevent you from doing this. The companies have a level of technical competency they expect from employees. Your first priority as a manager isn't to maintain that level of technical competency, its to have someone fill your headcount.
If they let you screen people, then either they let you waste other people's time on candidates who should have been screened out, or they let you make the final hiring decision, and you potentially hire someone who doesn't meet the global competency level. This ends up getting silos and requiring interviews to switch teams and having "weak" and "strong" teams and such, which is still sometimes a problem at Google, and Amazon, but no where near like it was apparently an issue in the Microsoft of old.
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...
So who at Google is using Google Docs to write their code, day-to-day? No one, right?
And 8 interviews? Was it even the last potential interview? That is indeed fubar. They do this because they can. Hiring is an expensive process, and not everyone can afford to dump this much effort into a single hire.
Pretty standard across these AmaGoogFaceSoft like companies. They basically have too much money and time to spend on these things, and they inevitable hire people like them who have lot of free time on their hands to prepare for their textbook puzzle questions.
In other words they wish to hire candidates who do bare minimum work but spend hours preparing for interviews to move to next jobs.
So in the realm of infinite knowledge and experience candidates may have, the signal you want is based purely on the specific contrived questions of your choice.
You should be aware this is not unbiased, it's just biased towards those who happen to have worked on similar problems to what you think is important.
Google can probably get away with this due to the size of applicant pool, but when I see other companies cargo-culting this approach I can't help but see a huge talent arbitrage opportunity.
in my opinion that disenfranchises the rank and file who should, and usually do, have as much interest and voice in the organization's future as the hiring managers
I'm happy to see i'm no the only one who has adopted this practice[1]. Sure enough, reading resumes filled me with bias about a person's assumed design skills, communication skills, organizational skills and attention to detail, none of which a resume is adequately capable of determining.
When i interview candidates today, i check a resume for 3 things: years they have been coding professionally, has their average tenure with companies been > 6-9 months, what languages do they list? It has yet to be a practice that has bitten me in any way i can identify. In fact, i feel i give candidates a better chance when im not criticizing their resume before meeting them.
Uh, what? Every time I've done an interview, the first thing I looked at was the candidate's resume. Even ignoring the fact that everyone is different, has different experiences, and is strong/weak in different areas (which is very important to know as an interviewer), I'm not sure what kind of bias you're trying to avoid.
FWIW, I’ve seen the same practice advised in “unconscious bias training”. The idea being that if you notice that someone went to the same university you did, or a prestigious university, or worked for a prestigious company or a company you worked for, you’ll be unconsciously biased in their favor. The antidote to unconscious bias is to have a standardized interview and a standardized rubric for evaluating the candidate’s answers and to disregard any other information.
I’m very deliberately not sharing my personal opinions on this.
I am skeptical that standardized rubrics can help but my approach is more effective and easier anyway, at least for things you can avoid knowing. Doesn't help with race or gender bias though unfortunately.
The recruiters tell you if they want you to ask questions about specific topics and realistically I'm only going to get to ask one question anyway. The main bias that I'm trying to avoid is knowing what school the candidate went to.
You seem to be getting beaten up over this point, so I'd like to un-lurk and support it.
A screener's job is to read the resume and match static facts to company needs. A recruiter's job is to gauge subjective fit and mutual interest.
An interviewer's job is to assess analytical ability, communication skills, personality, and culture fit, as well as to be an advertisement for the company/team/project/position if both sides want to close the deal. None of that depends on a re-evaluation of the static facts on the resume.
If I interviewed with a CEO or VP of Engineering, and that person asked me questions about my resume, I'd run away as quickly as possible from that company. I'd do the same depending on the circumstances if an engineer referenced my resume during an interview.
>> If I interviewed with a CEO or VP of Engineering, and that person asked me questions about my resume, I'd run away
What else are they going to ask you about? If my resume highlights my notable accomplishments in XYZ and the VP of E asks me if I have any interest in doing XYZ then I am going to consider the VP of E to be a total idiot or incredibly distracted.
I don't care about XYZ. The company you came from already did that. The world doesn't need another XYZ. But we do care about XYZ', and we think someone with experience in X, Y, XY, YZ, XZ, XYZ, WXY, etc. will help us build the first XYZ' in the industry. That's why the screener picked your resume among the 500 we received.
So I'll ask about XYZ', because that's what we're going to build.
(We're actually building ZYX''', but that's a secret we'll reveal once you join the team.)
I think that approach is misguided. The resume has background information and my opinion is that interviews do not correctly capture the capabilities of a person.
Yeah but I'm not the person making the hiring decision, I'm just the interviewer. The way this works at companies like Google is that the interviewers submit feedback to the hiring committee and the hiring committee decides.
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.
How do you interview someone more experienced than yourself?
In the last set of interviews I had to do, I've ended up doing the role of talking to people about the technologies listed on their CV and asking them detailed questions to find out just how well they really know them. This just because I happened to be the person in our company who knew a little bit about most of the things that the people we were interviewing claimed to be good at.
Sometimes you have a really nice technical conversation with them and discover that they're clever and knowledgable. Sometimes you uncover a blagger trying their luck. Sometimes a bit of both. So, it's a useful part of the interview I think.
So very recently we interviewed someone with 30+ years of experience, more than any programmer at our company (only 3 developers), and much more than myself (8 years).
So I went away and did a little bit of research about the technologies he'd talked about: COM and Corba and JBoss and other artefacts 80s and 90s, and tried to ask some questions in as respectful a way as I good, and I hope he wasn't too annoyed. In the end he was great (actually I found his enthusiasm and attention to detail pretty inspiring) and we hired him.
I can definitely see how a person would be annoyed by that sort of probing though, especially when the interviewer doesn't know what they're talking about.
The alternative is for our field to have a strong organization that vets it's members, like any other professional field such as lawyers and other engineering disciplines. That way, before you even meet the person, you can assume a level of competence and can get into much deeper questions faster.
I guess the irony is that most of the interview tactics now focus simply on comparing candidate A to candidate B, in contrast to learning about candidate A or learning about candidate B and evaluating their suitability based on their skills and experience.
If you ask both candidates a question like "Johnny climbed up to the top of the hill, where was Johnny when he stopped climbing?" and then get a blank stare from both candidates then you are going to conclude that you can't find any 'qualified' candidates because they can't answer a dead-simple question.
The vetting of candidates used to be contributions to software product releases and publications (in addition to degrees and GPA). A motivated hiring manager could also search mail archives of popular open-source projects.
And then all the high-paying jobs will go to people who went to MIT and Stanford, and if you're great but couldn't afford more than community college, tough luck, because your credential is the same as other people who barely finished high school.
It doesn't sound to me like you did anything wrong. I think what I have in mind is more subtle than just asking questions. I don't have any objection to being asked questions in general. I would prefer you ask questions appropriate to the claims I'm making about myself - that is, I'll feel more insulted if you ask more than a couple of remedial questions. You may suspect I'm a fraud, but beware of communicating to me that you suspect I'm a fraud.
> 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.
I have had a pleasure of interviewing a 'veteran' who listed both Emacs and vim on his resume, among dozens of other keywords and many, many years of professional experience. I asked him, how do you exit these text editors? "As any other program", he answered, perplexed - "you click on the cross in the upper-right corner".
This was not an unique and ever especially outstanding event in my interviewing experience.
That you believe you can judge any developer by how they use their text editor is one of the most pitiful things I've heard on this topic yet. Every time I begin a new job, I pray I'm spared crossing paths with people who think like this.
I certainly can judge them for lying on their CV. As I explained in another thread, from my further conversation with him, this developer obviously had no clue about either of these text editors and clearly included them in his CV just as random keywords.
When I asked if he was using a console version or some wrapper that supported window manager, he didn't understand the question. When I asked if there's some another way to close it, he, just as surprised, told about the main program menu, just below the window title.
Any person who actually used either of these editors even once would have a pretty solid idea of what I was going for. It was a very simple, quick test to determine that he just assembled his CV from semi-relevant keywords at random.
I don't know if I believe that. Lots of people (in particular folks using Windows or Mac) use the GUI version of those editors because they're preinstalled on machines at school and work. They may not even know there is a console version of those programs. (Also "window manager" is pretty *nix-specific jargon.)
I get that someone might use the default text editor. But where would a vim/emacs variant be installed that way? And if it were, why would it last for a novice any longer than "um, this is weird and doesn't do anything". Vim and emacs are only tolerable if you put the effort to learn how they work. And if you did, how would you get to the end of a tutorial without learning how to quit?
You're right, it's technically possible, but the parent is justified in being really suspicious that someone is citing familiarity with both emacs and vim and is confused that there's a non-mouse way to do something.
Graphical Emacs/VIM were installed on the CS lab machines when I was in college. I’m pretty sure they were part of the default programming environment setup at my first workplace. GUI versions of these apps behave a lot like regular Windows or Mac apps. You can save with CTRL-S, etc. I can totally see how someone could be very experienced in using it and never know there is a keyboard shortcut to quit apart from the ‘x’ on the title bar.
The question would have been better if it was directed to an Emacs feature for which graphical versions didn’t obey ordinary Windows conventions.
The whole point of vim and emacs is that you can do everything from the keyboard and not have to switch your hands to/from it. Fancier versions (like Macvim, which I use) support the same basic premise.
Now, certainly, with the fancier GUIs you can absolutely use mouse inputs. But it's quite a bizarre scenario where someone would be using an interface narrowly optimized to use the keyboard for everything, and yet still consistently use the mouse to exit "like every other application". The reason you use emacs/vim is to keep your hands from having to leave the keyboard! Why would you do that and yet not use the standard command for quitting? Not even ctrl/cmd-Q?
The parent is right to be suspicious of someone claiming extensive emacs/vim experience while using the mouse as a default option for a frequent, required command.
FWIW: I'm a Macvim user that has never quit it by clicking an X even though I know it's possible (at least for the individual windows). Although also FWIW I don't use the vim window feature and would fail questions about that.
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.
For an engineer who is doing an interview it is hard to judge those things written there. There are other stages (i.e. before an techbical interview is setup) where those are checked in depth.
For the technical interviewer knowing a bit about the candidate can help to start in an area where the candidate should have experience and then move into the direction you are interviewing for, of you have a clear set of requirements for the job however can also directly start there.
To avoid bias? As in to be completely unprepared? Wouldn't reading the résumé give you a better idea of the interviewee's background, and allow you to better assess him?
At Google there are two layers of the hiring process. Interviewers provide information for the hiring committee. The hiring committee has the resume. They don't need people to read it to them.
So, when I interview someone, I ask them some technical questions and maybe some questions about their work, and provide structured feedback to a seperate group of people who make final hiring decisions.
There's actually not a whole lot of reason for me to look at their resume. The group who makes hiring decisions has it, so my interpretation of it won't be that valuable. Potentially I could ask them to elaborate on some of their prior work or projects, but that's usually less meaningful than just asking technical questions.
I'm not there to figure out how good the candidate is at the things they claim to be good at. I'm there to figure out how good they are at the things the company wants them to be good at.
(Not trying to claim that I'm actually able to figure out much of anything in a technical interview, but that's the goal.)
In standard American English, masculine is the default gender when the subject is unknown. So using "him" is proper. Using "them" as a singular pronoun is jarring to the ears.
I was not aware of this, I've mostly heard "they"/"them". I take "he" to be an awareness or assumption of the gender, and find it quite uncomfortable to hear with regards to an industry with such a strong gender imbalance.
I am not sure I understand your position. So you would not get a lawyer to review a business contract because doing so would imply that your business partner is a lying scumbag, a morally unacceptable position when starting a new business relationship?
No, and that's called due diligence. Same with hiring. I have come across enough candidates where there was a huge gap between claims written on the CV and what the candidate actually did or knew to blindly trust any CV.
And the best candidates are often not the best CV writers.
Yes. And that this kind of discovery - especially detecting if they lied at you in written text, which for me is an exclusion criterion - requires having read the text...
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.
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.
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).
I had this when I applied as a grad. I wasn’t clear what they were looking for so I asked if they were looking for algorithms and language agnostic programming ability, or whether they were looking for Java and Java standard library knowledge. They wanted the latter, just Java. I didn’t continue my application.
If I got that response I'd tell the recruiter that "I'm not an RCG programmer, I'm a systems engineer, and that stuff has no relation to the actual work I do." Than I'd ask them not to call me again.
I wonder whether there is some perverse pleasure from trying to make an honest hardworking technically accomplished person who contributes something good to the world feel like a loser.
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.
I don't get it. Integers include negative numbers, so -4 and 4 are both integers.
Why would you select C? Because you're assuming the recruiter doesn't know what an integer is, based on the fact that all the answer choices are positive integers?
I think the point was to deliberately choose an example that would be understood by most the readership but sufficiently technical that it might be seen as an ambiguous question to someone less technical.
Reminds me a bit of those facebook clickbait posts "This question is so hard that only 5% of people will get it right"
I actually mean it as a real example. If given this stupid question I would actually, in real life, choose 4 (while knowing it is the incorrect answer.) This is due to the exact phrasing and the other choices given.
I think we'd all agree the correct answer is E, but I had multiple math teachers regrade my tests with higher scores after I pointed out that there were multiple correct solutions to the problem. In several cases, other students had provided the same solution I had but assumed they were wrong because the graded test said so. And these were tests the teachers had used for years. So let's change the question: if you're a student taking this test, how do you make sure that you didn't lose points because the test writers thought that C was the right solution? Or do you just trust public educators to grade you correctly?
Well the incident that sticks out in my memory was actually the kind where you show your work and circle your final answer. And as long as you get that work back and are confident you can then re-check the problem and can appeal with the teacher. That's a little harder to do with multiple choice because you have to replicate how you arrived at the answer you did, but the bigger problem is a general process problem. Standardized tests often don't yield individual results to the test-taker, so you're entirely dependent on the test writers and whatever review they seek out to ensure it's correct. And standardized test writers have been known to have some pretty BS questions (there was an article around where an actual author whose writing was used as material in a standardized test didn't know the answer to the questions being asked of students).
Having tutored my 13-year-old daughter through algebra this school year, a common mistake is flipping this into a square-root problem.
As asked, the question is about mappings ℝ+ → ℝ ⨯ ℝ ∪ {0}. Square root is different, mapping ℝ+ → ℝ+ ∪ {0}. The question could have been sloppily worded or someone trying to make it look more “mathy.”
When I tell my daughter that negative numbers have square roots too and are imaginary, she rolls her eyes and sighs.
There are different clues in different contexts. The hardest is if there is a very technical definition that makes another answer more correct.
Maybe in a test of English:
"John has less _____ than Mary. So they decided to go to Mary's apartment for breakfast."
A. Bread
B. Window
C. Eggs
D. Times
"
This is an incredibly stupid question oh my God. What would I even pick.
All of the choices, and the whole question, is so stupid.
But anyway obviously they want you to pick "eggs" because you are supposed to know it is good for breakfast. You can tell how low the bar is by its inclusion of window, as though you might not know this simple word.
It is ungrammatical to say "less window than", "less times than" and "less eggs than" (you're supposed to say fewer eggs than.)
Only "bread" is grammatical in that sentence and it makes just as much sense as all the other stupid choices, but I would pick the ungrammatical choice C (it's a hard one though, the resulting sentence is stupid) versus the grammatically correct choice A.
Yes but from "times" you can see that this is a test of VERY basic English. I agree with you that Bread is both correct and fits the context better, and I would still choose "eggs" (a worse answer, from the choices given) because I would analyze what the (really stupid) question-writer wanted.
You are right that window exists in that sense but in this case it's clear that the question writers didn't think about it.
For "window" in particular, we rarely say it the way you imply, the whole Internet has just 4 instances of these words after each other:
(you can try 'have' and 'has' for 'had'). But you might be right that the informal sense of "window" that I think you imply (window of time) might be technically the best answer in a different context but absolutely not the answer to pick!
So it actually is a good example of a potentially better answer that you shouldn't pick after analyzing the question!
This is specifically what actually makes it, eggs, objectively wrong -- though it is the choice that will be marked correct and which you, the test-taker should pick, even if you realize it is wrong. Pedantically, it is wrong to say "less eggs" while it is correct to say "less bread" but due to the level of pedantry, you, the test-taker, should prefer to pick the incorrect answer (eggs) over the only actually grammatical answer (bread) - even though this is a test of English.
You have to set aside what is correct and incorrect and decide how educated the test-writer was, and what they might want you to pick, or what they are attempting to test.
This has direct relevance to the article are discussing.
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.
> 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.
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.
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.)
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."
It's possible that the process didn't permit much back and forth clarifying of concepts or questions. It does seem that way reading between the lines. I've had some similar experiences over the years (not with Google) so it seems at least plausible to me. It's also possible, if not likely, that the author of the OP was upset, felt slighted, and is not remembering things as clearly as he or she thinks.
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.
Google does many hundreds (if not thousands) of these a week, and this false-negative is an unfortunate casualty of the process.
Yes, and it's worth remembering that Google are the unfortunate casualty here. Being rejected as a false negative sucks as a candidate, but ultimately there are plenty more developer jobs around if you're actually good. As a business rejecting the right person could cost hundreds of millions of dollars in lost revenue, mistakes, and bad PR.
Google believes the opposite, that hiring the wrong person could cost that if they have a negative impact on the teams they work in so they prefer false negatives over false positives.
The lawsuits happen because people don't have real savings due to high cost of living/lifestyle inflation and reliance on employer benefits. If losing your job wasn't such a potential death sentence, I think it would be easier to fire people.
It's hard to square that with the whole 10x engineer thing.
It is true that hiring a security risk could be more damaging than rejecting a super talent, but all companies have systems in place that should reduce impact of incompetence and manage out inadevertantly hired incompetent people, because no hiring proccess is perfect.
So about rejecting a super talent to avoid hiring an incompetent person. It seems that statistically, a minority of people produce a majority of the value. Google hires in bulk, and I doubt their Cal Tech manufactured Mc Engineers are all elite people, so I'd guess they have the same problem as anyone else.
That problem is hunting for these people who will drive your buisness forward. Like YC and startups, you need to hire a bunch of bad bets for the big payoff.
>It's hard to square that with the whole 10x engineer thing.
That's because Google doesn't particularly ascribe to this idea. With good infra, tooling, and environment (management, mentorship, etc.) anyone can be "10X".
>manage out inadevertantly hired incompetent people, because no hiring proccess is perfect.
I'm not sure I've ever met an engineer at Google who I would call incompetent. Certainly some who are less competent than me, certainly some who are more. Certainly some who have made singular technical decisions are think are wrong or bad, but none who are incompetent. The hiring process is the system you describe.
If they keep screening out A level candidates and are forced to hire C level candidates because they studied the prescreen questions and are the only group left. You will find competent employees but you are not getting the best anymore.
Why are A level candidates incapable of studying the questions?
Someone who's A level in my book knows how to get the tasks in front of them done. If half the steps to getting them done are beneath them, they do so anyway. If one of the steps is stupid political nonsense, they do so anyway. Someone who is amazing at hard technical problems and refuses to do anything else on principle is not a worthwhile hire.
That matches my observations from dealing with Googlers: So far I've met quite a few very nice and clever people and none that made me questions their competence. Quite the opposite.
That's totally fine. The problem is this way is a dumb way of doing it. Send out screener coding questions and have an engineer quickly review the responses rather than someone with a business degree that has no idea how to speak the same language an engineer would.
>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.
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.
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.
>This is the pre-screen, very likely conducted by a poorly-trained (or incompetent) recruiter.
Which is embarrassing. Their brand means that they can hire the best people. They have the money to hire the best people. There's literally nothing stopping them from hiring recruiters who have an ounce of competence except themselves.
It's not even like this can be blamed on the recruiter in question - they clearly have a systemic problem.
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.
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.
That's familiar. Towards the end of my Google interview 10+ years ago I was asked "What do you think Google could do better?" and my answer, which was constructively framed in terms of my wanting to help fix it, led to the technical interviewer saying "Well I won't waste any more of your time."
Like OP, I was told that I was interviewing for a managerial position (in my case, a PM in SRE) but was given a technical interview that seemed designed for recent grads (I had about 10 years of experience at that point). My interviewer was < 6 months out of a grad program and seemed to have very little context for functional or programmatic management and mostly asked me a bunch of big O and algorithm questions. I was doing pretty well until I had the audacity to suggest that maybe the Google Docs/Drive/Whatever needed to be better integrated at the time.
My sense was that they were looking for extremely pedantic and detail-oriented programmers and nothing that I was being asked had to do with real problem solving, design, abstract thinking, or interpersonal skills.
Seems like a complete wast of time in an interview. If you join then sure mention it, and if your rejected you can send an email or something but it's not constructive during an interview.
We interview specifically for people who can give and take constructive criticism. There are points in our interview process where giving a rational and constructive critique of our product would be a very good thing for a candidate. These are skills we value highly as they help employees improve faster.
We also do check for negativity in candidates though to balance this. Critical feedback can be given effectively without needing to be rude or unpleasant.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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?
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.
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.
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.
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.
Don't laugh at me. I didn't even state whether I support these questions. But if you don't know your way around basic shell gotchas or can't tell how many bytes are in a MAC address (or can at least conclude it by remembering working with them), you likely haven't worked enough on the command-line / haven't worked enough in networking. There's nothing funny about it. If you don't agree you're just a bitter cynic.
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.
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.
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.
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.
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.
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.
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.
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.
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.
As others have pointed out, this is just a filter for Google to see who wants the job the most and is willing to jump through the most hoops.
Google misses a lot of good candidates but the ones they get are good so they do not have to care about the broken process.
One could even say that this broken hiring process encourages the customer-averse CS automation nightmare at most Google products.
Hypothesis: Someone who experiences a hazing ritual to get a job at Google is less likely to worry about being nice to customers and will try to automate all customer facing interactions.
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.
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:
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.
(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.
> 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.
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.
"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.)
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?
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)
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.
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
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.)
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"
But of course they wouldn't implement it in such a way.
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.
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.
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.
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...
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), 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 (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.