Google's “Director of Engineering” Hiring Test (2016)
gwan.com
gwan.com
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.
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.
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.
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.
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.
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 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 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.
Is this really true, though? Are they losing out on more top end candidates?
There are other places with interesting work and big paychecks. Some of them aren't building reputations for annoying interview processes.
Also, I linked money since the parent comment talked about finding interesting ans similar paying role as Google's.
(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.)
Except for all of the other big tech companies?
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.
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.
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.
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.
(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.
Have a source for that?
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.
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.
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.
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.)
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.
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.
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.
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]
[1] https://www.glassdoor.com/Interview/Google-Director-Intervie...
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.)
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.)
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)
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.
He neglected to respond.
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."
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.
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.
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.
Real mature, Google.
So stop right there and run back into your PR cave.
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.
Anyway, I strongly suspect they're just misremembering that question.
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.
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.
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."
Interviewer: "Wrong. It's constant."
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.)
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.
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.)
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.
riiiiight
> 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).
Riiight.
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").
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."
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.
2. He misheard the question.
Point is: arrogance isn't the curse you might think it is.
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.
It might be that the app was a foot in the door but might not be applicable past that initial point
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"?
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.
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.
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?
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.
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.
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.
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.)
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.
Please take a look at my defense of the retelling being about 80% true, and Google doing exactly the right thing: https://news.ycombinator.com/item?id=12702726 + my reply below
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.
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>
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.
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.
which begs the question, what are all those software engineers actually doing?
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...
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.
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.
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.
The question would have been better if it was directed to an Emacs feature for which graphical versions didn’t obey ordinary Windows conventions.
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.
In the last set of interviews I had to do, I've ended up doing the role of talking to people about the technologies listed on their CV and asking them detailed questions to find out just how well they really know them. This just because I happened to be the person in our company who knew a little bit about most of the things that the people we were interviewing claimed to be good at.
Sometimes you have a really nice technical conversation with them and discover that they're clever and knowledgable. Sometimes you uncover a blagger trying their luck. Sometimes a bit of both. So, it's a useful part of the interview I think.
So very recently we interviewed someone with 30+ years of experience, more than any programmer at our company (only 3 developers), and much more than myself (8 years).
So I went away and did a little bit of research about the technologies he'd talked about: COM and Corba and JBoss and other artefacts 80s and 90s, and tried to ask some questions in as respectful a way as I good, and I hope he wasn't too annoyed. In the end he was great (actually I found his enthusiasm and attention to detail pretty inspiring) and we hired him.
I can definitely see how a person would be annoyed by that sort of probing though, especially when the interviewer doesn't know what they're talking about.
But, what's the alternative?
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.
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.
I’m very deliberately not sharing my personal opinions on this.
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.
I'm not following. Why would someone read the resume to someone else?
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.
(Not trying to claim that I'm actually able to figure out much of anything in a technical interview, but that's the goal.)
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.
1. https://blog.benroux.me/resumes-make-hiring-harder-ignore-th...
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.
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.
I also found history the most boring subject in high school. Probably not a coincidence.
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.
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.)
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.
First, our problem statement: filtering phone-screens by recruiters is resulting in poor experience, false positives, etc.
We thought about potential causes, but instead opted to look at the logistics of the call: recruiter runs process, gets responses, and then returns to engineering with feedback.
It was a vacuum filled with innuendo, unspoken assumptions, you name it. Collectively, our recruiting operation was an echo chamber.
So we asked if we could have recruiting calls recorded and/or transcribed. Candidates had no problem agreeing to it -- the recruiters were reluctant at first. (You can probably guess where this going...)
We recorded/transcribed maybe five calls, and that's all that was necessary. We saw dramatic improvement, and we owe most of that to the Observer Effect. We maintained the same throughput of candidates, but we saw more ideally-suited candidates pass through as well as heard better experiences from candidates.
I'd suggest most any operation try this.
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).
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.
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?
Reminds me a bit of those facebook clickbait posts "This question is so hard that only 5% of people will get it right"
I guess the US has multiple choice tests at all levels.
https://www.huffingtonpost.com/entry/standardized-tests-are-...
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.
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.
This is just a technical distinction though.
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:
https://www.google.com/search?q=%22had+less+window+than%22
(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!
You can have “less bread”, or “fewer loaves of bread”.
This is getting very pedantic though.
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.
Interviewer: What is the difference between a mutable and immutable string?
Me: A mutable string can be changed. A immutable string cannot be changed.
Interviewer: Nope, think mutations. Mutable string can be mutated.
Me: Mutated? Altering DNA?
Interviewer: If you don't know this there isn't any sense in asking more difficult questions.
Me: Floored.
Yeah interviews have been rough this time around. Before this I hadn’t interviewed in 10 years.
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.
(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.)
"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."
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Not rocket science, everybody. Who knew that people don't respond well to being criticized by strangers! Nobel Prize.
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.
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.
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.
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.
for (i=0; i<NUM_QUESTIONS; i++) {
Interviewer: [Technical question]
Me: [Answer]
Interviewer: That's right!
}
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.
Yep. :-)
> Didn't they remember you?
If they did, they hid it well.
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".
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?
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.
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.
Even Jeff Atwood tweeted that he does this the other day.
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.
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.
"Answer these questions three, and a GOOG employee you shall be!"
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.
I would have said that I would multiply 10000 by 16. Oh well, no Google job for me I suppose.
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.
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;
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.
Contrast that to being able to read the memory straight through and having it prefetched, then using the popcnt instruction:
Pedantic but, the LUT would also remain in the cache if there wasn't some issue with cacheline contention.
Although, I do agree that POPCNT + prefetch and unrolling will do much better.
These false negatives are avoidable with a better-designed screening process.
This "exact match" issue is why we use multiple choice questions (pick from 4 choices) for initial technical screening. If you know what you're talking about, the format is far more forgiving to all of the cases described in the post, as you can rule out obviously incorrect answers. If you don't know what you're talking about, your odds of doing well are are stacked against you after a few questions.
Once you're doing a video interview with one of our engineers, we know what makes sense, can ask follow-up questions, and if you plausibly know more than we do about a topic, can make a note to look things up or ask our teammates in #interviewers.
(Note: we're hiring remote engineers to grow our interview team: https://news.ycombinator.com/item?id=16815444 )
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.
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.)
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.
"Bullet dodged" -- he did you a huge favor.
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)
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.
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
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.)
But of course they wouldn't implement it in such a way.
This is a bullshit article, why did it frontpage again ?
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.
> Thought: I guess that's what happens when AI bots discover recreational drugs.
That's why engineers should be interviewed by engineers.
If they were looking for a human they would have used a captcha.