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).
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.
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.
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 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.
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’m not sure I could take more than a couple of those extremely petty replies from the interviewer before I would just tap out.
Why even bother having this interview conducted by a human when they display as much nuance and understanding as a Scantron? “Quicksort is the best sort, period.” Fuck off.
> 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>
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.
>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.
>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.
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.
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.
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.
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?
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.
> 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.
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.
>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.
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.
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.
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.
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.
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.
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.
>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.
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...
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".
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.
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?
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.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
"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.)
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.
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.
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 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...
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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'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.
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
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.
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.
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 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.
343 comments
[ 2.8 ms ] story [ 231 ms ] threadHowever, 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.
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.
Why even bother having this interview conducted by a human when they display as much nuance and understanding as a Scantron? “Quicksort is the best sort, period.” Fuck off.
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'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 had applied for a developer position and they wanted to interview me for a systems engineering position.
I said "I didn't apply for that position as I don't think I qualify for it" They said "Just go with it".
Predictably, I bombed it, one question I remember is what is the name of process id #1 in linux.
Never applied at Google again.
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.
https://news.ycombinator.com/item?id=12701272
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.
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".
"Answer these questions three, and a GOOG employee you shall be!"
But of course they wouldn't implement it in such a way.
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?
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.
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."
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.
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.
[1] https://news.ycombinator.com/item?id=6070001
"Bullet dodged" -- he did you a huge favor.
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 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.)
https://en.wikipedia.org/wiki/Singular_they
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.
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.