I interviewed at Google about a decade ago. I made it far enough that they flew me out to interview on-site at their Kirkland office.
I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed.
Well why the hell not?
The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again.
I didn't happen to know that particular detail at the time. It derailed the entire interview. He was fixated on this one very specific piece of knowledge. And the worst part is not only does his approach make your code less clear, there are also contexts under which it wouldn't work.
I don't know if that particular interview was the reason for my not being offered a job.
I did end up hearing later on about hiring from a couple of Google engineers at a tech conference. They said that it is quite common that Google makes you interview two or three times.
I suspect the reason is to make you feel a sense of gratitude for being hired. And so you don't quit.
> The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again.
I almost wonder if he was really looking for an objection to that proposal, and specifically the reason for the objection.
It's the kind of thing I might do but I'd freaking TELL you, and in time so that you know how to handle the rest of the interview.
I don't think it's wrong to have a test that exceeds the range of the tested. Really no one should ever ace any test, else the test is insufficient. Thermometers don't just go up to room temp. So a sneaky question that only a truly insightful and thorough person might get, and ballsy enough to challenge the interviewer, and with good enough judgement to know when it's right to talk back, that I myself might not get, is fine. But it's there to identify the exceptional, to provide room in the plot for the spikes instead of clipping, not to kill everyone else.
I sometimes give people way too much credit though. I bet it was all face value.
Another point on your side is that close(); open(); is racy in threaded programs: to avoid the races you need to use dup2(), but that still has caveats related to losing errors from close().
> He was fixated on this one very specific piece of knowledge.
IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers. If you only know one, your question is shit and you might as well have the applicant play guess the number.
That is silly. Trying to know all the possible answers is a losing game.
If I as an interviewer ask that same question and get the freopen answer, and let's say its not one I'm familiar with I can just simply say "I'm not familiar with freopen, could you tell me more about it?" And then I listen to what they say. A competent developer who is worth their salt will be able to summarise the gist of it quickly. Then if I want even more info I might describe the solution I know about and ask the interviewee to compare the two solutions, describe the pros and cons as they see them. What I would be looking for is the proof that the person I'm talking with is able to communicate complicated things clearly, and can think about code.
These skills are exactly what one needs in their everyday work, so why not use the opportunity to evaluate them? Does anyone really think that the goal of an interview question is to query if they know that specific trivia you happen to know?
And besides if I have doubts about that they are just hoodwinking me with this freopen I can just crosscheck what they told me with the reference. If it turns out to be not a thing at all, that's not a good sign and I will not recommend them to be hired, but otherwise they passed with flying colours.
Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc.
If you just fixate on your specific first solution and choose to dig in and argue over it despite your interviewer not liking it, it's not a good sign you're someone pleasant or frictionless to collaborate with.
> Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc.
Trivia questions like that are absolutely awful for demonstrating any of what you're talking about. There isn't any creativity involved. And it's not like the guy followed up with something like "where would you go to determine the answer?"
There were 6 or 7 other interviews I went through that had interesting, open-ended questions that allowed me to bounce ideas off the interviewer and share my thought process. This particular interview was not one of them.
"not a good sign you're someone pleasant or frictionless to collaborate with"
That sreet must run both ways or it's an invalid charge. If you're reasoning is valid and the interviewer doesn't provide better arguments, then it's the interviewer who is not pleasant or frictionless to work with.
I wonder how dependent Google’s hiring pipeline has been on just having a huge % of every qualified candidate attempting to get a job at Google? If that is the case, then the interviewing process just needs to be good enough to have a low false positive rate. The false negatives don’t hurt them.
I'd be willing to bet that has a lot to do with it.
In my younger years I remember being in awe of the simple fact that a recruiter from Google actually reached out to _me_.
A decade changes a lot, though. I don't think I would ever want to work at Google now. I'd be curious to know if my shift in perspective on Google is common, and if they're even aware of it.
While I can't tell you how common it really is, I can tell you that we're at least two here. Same with the Amazon recruiters that reach out from time to time.
I absolutely do not want to work for Google. There's an office near me, and the few times I've been considering another job, I explicitly decided not to even send an application there. It sounds kinda like a dead-end hellhole to be honest. So it's not just you.
When I was young, a Google recruiter reached out to me and I joined the firm. It was the good years and I enjoyed it a lot, learned a lot too. When I was older I quit. I wouldn't want to work there now. The company seems to have changed in deep ways for the worse :(
In universities Google and FB are now seen the same way as law firms and hedge funds were seen 20 years ago. A boring place where you go to have an upper middle class career and be conventional. Which means they are ripe for disruption.
That’s a terrible interview question. I haven’t been at Google long enough to comment on hiring practices a decade ago, but nowadays I wouldn’t be surprised if an engineer who asked that type of question got feedback from HC to change their question.
I think that about a decade ago they still used horrible "why is manhole round" questions or "guess the trick" ones. The kind which puzzle-obsessed geeks like to ask eachother but which are horrible for evaluating fitness for a job.
This changed. I interviewed 7 years ago and they have fixed this, judging by the questions I got and the interviewer training I received. Using trick questions and fixating on "the" solution was explicitly called out as bad.
Of the questions I received two were open ended design questions and the rest was about algorithms and implementing them.
This happened with my onsite interview as well. I was working on local, user-based systems and hadn't done anything with networking/web-scale/sharding/etc.
I did very well with data structure questions, and had one difficult interview and one question about sharding a globally scaled system. I had never dealt with anything on that scale, and didn't even know how to think about it.
I realize that there was a gap in preparation, and I'm confident that that one interview out of 8 is what nixed my chances.
I had a similar, but not the exactly same issue recently, and about 2/3s through the interview I was stopped and the interviewer kinda poked at my resume and successfully deduced that my prior work experience was just not at the level/scale the company was looking for. How do you prepare for that without having actually worked on that scale. Oddly, I ended up getting an offer for a different position after that though.
I can read about subject X all I want, but I would never be confident enough in an interview at just that. And large scale applications isn’t something I can just something I can replace with a side project.
Out of curiosity, which kind of position within Google were you applying for? And how did you sell your own expertise?
This sounds like a really bizarre and very specific question for the interviewer to fixate on, unless it was particularly relevant for the position. Knowing the details of how to best do the redirect doesn't seem relevant for a generalist interview; this is the kind of thing you end up, well, googling when you need to do it. I suppose a kernel developer is supposed to know this though, were you applying for kernel development?
It was an SRE position. My technical experience has always been fairly general but largely infrastructure-focused and I had a computer science BS when I interviewed.
C only came up because I was asked to provide a list of languages I knew, and rate on a scale of 1 to 10 how well I knew them. At the time when I interviewed, I said I knew a little C (I had used it in a bunch of my CSCI coursework and some small personal projects).
So yes, it was an absolutely stupid thing to focus on.
I had a similar experience in a problem in which I was requested to extract the digits of an integer before performing some other task. I proposed doing this by converting it to a string and extracting the digits from the string, and that was rejected arbitrarily even though it solved the problem at hand just fine. So I spent entirely too much time during that session recreating an algorithm to extract digits via repeated division/modulo operations that would likely be much slower in practice.
> repeated division/modulo operations that would likely be much slower in practice.
… but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed.
I don’t know enough about the question, but it’s possible that the interviewer wanted to test this specifically. I’ve had interview questions which were literally “implement itoa.”
In this case where itoa was part of a larger question, if I was conducting the interview I would let you convert to string for now so you could continue, but I would let you know that I wanted to revisit the digit conversion later.
It's still not as efficient since you're breaking on base 10 digit boundaries, not base 2, the most efficient encoding will be base 3, but alas we don't have ternary computers.
But it's a much more compact than that glibc monstrosity is. Sure, the glibc version will win in a micro-benchmark, but micro-benchmarks don't capture the effect on the instruction cache.
Using a decimal expansion adds 25% overhead from pure maths. Your cache will be larger if you're working in base ten regardless of what optimizations your compiler does.
i had a similar experience wrt a product position. interviewer was fixated on a particular 'right' answer to a trivia-based question. was gladly not a fit there.
The interview loop is not necessarily an indication of the work environment. It is a chore, 1-2 interviews a week, about a couple hours each including prep & report writing, evaluating a candidate that will not work on your team, except in rare instances. I can see interviewers zoning into a specific answer simply because they have no energy and no interest to explore alternative avenues.
This sub-thread is missing the forest for the trees.
This interview was not the highlight of the interviewer's day. They most likely didn't overthink every angle and every word. They probably were on autopilot looking for some pre-defined criteria - and could care less if the candidate was qualified, accepted, or rejected.
Right but Google really needs to be called out on the amateurism in interviewer training, selection, and quality control, as displayed throughout these comments. They clearly use volume and redundancy to make up for the number of failures.
I'm sure they'll come out with the argument "we give xx million interviews, we are within an acceptable failure rate with these outliers". No you're not Google. No you're not.
Google has hired ~100,000 people in the last decade. They have probably interviewed 30M+. Broad generalizations like "their interview process is failing" are pointless. You don't build a $2T company with a broken hiring process.
This keeps coming up but is worth repeating – the goal of any large company's recruiting process isn't necessarily to hire the best possible candidates 100% of the time. There are always trade-offs. Every interview takes time away from employees. There is no way to predict 5+ years of performance from a 1 hour interview slot. Education, credentials, experience are all valid data points but again not a great predictor of success. Hiring is ultimately an exercise in balancing many different priorities and hoping for the best result. Some able candidates miss out, which sucks, but that's factored in. It's also much more important to keep a bad candidate out than ensure every possible good candidate is hired.
Every single one of these articles/tweets/anecdotes boils down to "Google didn't hire me and I'm very smart so their system is totally broken".
Chill out a little. What makes these threads explode is that many many people have spent weeks or months of their lives preparing for an interview at Google - it can create a lot of reasonable resentment especially when one feels they haven’t been given a fair shake - and by many accounts even Google recognizes that there’s an element of luck involved even when the person is good.
This would be a good argument if google had diversified products. But it relies so heavily on one product it makes you wonder if engineering quality even matters to google's success. Google's Ad business can hide the worst systemic problems because it makes so much money.
In other words, google's success says very little about the quality of it's hiring process.
Much of Google's success was cemented in place back in the day when they recruited people by putting fun little puzzle inserts into computer magazines.
That's such a huge difference from their hiring practices now.
I reckon that coding as part of an interview is really just to make sure the person isn't a total fraud. There's that guy who for some reason thinks he can nab a high paid job by blagging it, and then there's the guy who thought he was a coder but it turns out that writing some VBA macros isn't quite the same thing. Those kinds of people will be found out immediately if you ask for a FizzBuzz type question, and that is maybe a reason to do it.
Beyond that, there's no point. You won't discover whether the guy who passes is the kind who writes undocumented spaghetti, or if he doesn't know how git works, or if he doesn't know how to assess an OSS library.
What seems to always work for me, having hired dozens of people over the years, is a technical chat. Tell me what's interesting. What's the difference between this language and that one? Why did you make the choices that you did? You talk, not me.
Someone who can say substantive things about different techs has spent the time. Someone who has formed opinions has spent the time. Someone who's spent the time won't run out of opinions.
I will concede that while this has worked for me, a hiring manager in small financial teams, there's a fair chance it won't work for Google. For one, nothing I've just recommended can be measured. It also can't be taught to junior interviewers, and thus relies a fair bit on the reputations of the firms on the CV for filtering. Finally, and perhaps most importantly, there's a big difference between the decision maker doing the interview and someone who is just an advisor (ie an agent) for them, in that the agent needs to have something concrete to say to his boss as well.
I don't get it. University tests are brutal too and have the expectation the student will devote large amounts of time and energy. It seems like a job interview is fair game for the same, no?
I feel like this is a very bruised ego here. I'm not saying any interview process is perfect, and I think a lot of them are very, very bad at accessing the capabilities and value someone provides, but same for University.
> I don't get it. University tests are brutal too and have the expectation the student will devote large amounts of time and energy. It seems like a job interview is fair game for the same, no?
No. That logic is just superficial pattern matching.
The point of university is to spend the time and energy to master the subject, test or no, and the knowledge gained is usually valuable in and of itself. The kind of interview prep in question is basically learning how to jump through some arrogant company's hoops, which likely has little to do with anything, including their actual job.
> The point of university is to spend the time and energy to master the subject
Really? I think most people go to college to get a good job before all else. With that line of thinking, an interview is just another of these “tests”.
But you make a good point about these arrogant companies administering tests. College faculty are never arrogant, but always humble like this guy in the article who just can’t chalk his failure up to being a human being.
> Really? I think most people go to college to get a good job before all else. With that line of thinking, an interview is just another of these “tests”.
That's called credentialism, and it's a perversion of what universities are supposed to be.
> But you make a good point about these arrogant companies administering tests. College faculty are never arrogant, but always humble
What a red herring.
> College faculty are never arrogant, but always humble like this guy in the article who just can’t chalk his failure up to being a human being.
Let's review that professor's story:
> Jacobson has no trouble admitting he totally blew a basic test at the beginning of an interview for a fairly elite job at Google. He has no expectation that had he passed the test, he would have earned a place at the company down the line. He has a problem with the fact that a company with the power, prestige and wealth of Google has developed a recruiting process that is so large and systematic that it can both ask for large amounts of time and energy from prospective candidates and then easily or accidentally hurt or dismiss those same qualified candidates because of a difference, like Jacobson's cognitive disorder.
Does that sound like arrogance to you? Ignoring the sarcasm for a moment, there's a difference between being humble and being a pushover, and it's more of a pushover thing to overlook glaring problems in a process in order to blame oneself.
His story also brings to mind another salient difference that undermines your attempt to compare a Google's interview process to the ACT/SAT: if you flub a standardized test, you can easily retake it. That's not so much the case with an interview.
> What is the SAT/ACT if not jumping through hoops?
I wouldn't call those "university tests." Also, you can do quite well by just mastering your High School subjects without extra test prep, and the stuff tested (e.g. Algebra) is stuff you'll actually build on in university. They're also standardized, so even if you decide to do test prep, it's not like you have to prep for different exams for each school you apply for.
> University tests [...] have the expectation the student will devote large amounts of time and energy.
It's reasonable for universities to have that expectation because being a university student is considered to be a full-time occupation. It's unreasonable to have that expectation for working professionals. But Google and other big tech do it anyway because there are thousands of people waiting in line to interview.
The brutal interviews become useless if they assess trivia you won't use in your job and you would google if you had the time, and also if they don't measure your ability to learn and adapt, or to take things seriously and responsibly.
People rail against these because they are not only brutal, they are a waste of time. We also suspect they have little correlation to actual employee performance once hired.
Steve Yegge, ex-googler, also mentioned the common phenomenon of the interview anti-loop that used to happen at Google: two interviewers in your queue would not have hired each other, so the attitude/knowledge which would satisfy one of them will actually get you rejected with the other.
The point of attending a University is that at the end of it, the University confers upon you a degree that asserts your knowledge in the relevant field of study. That degree is valid forever; the University doesn't later get to take it back if you're actually a buffoon. You receive the credential, it has value, and its conferral is guaranteed as long as you complete the requirements of the degree.
By contrast, interviews are extremely condensed and an interview doesn't guarantee you a job in the same way that completing degree requirements guarantees a degree. Employers also have the option of firing you later.
The stakes at university are miniscule. If your kid needs shoes, if your landlord is calling before the interview asking where their money is, if you have a medical condition (which universities account for, but most employers do not)...I am not having a pop at you, but what world do you live in? The purpose of university is to study, the purpose of a job interview is not to study. As I explain below, it is clear to me why Google make this error in confusing the too...it is baffling that anyone else views this as logical.
Btw, be totally clear, this has been a bad outcome for Google. Google's failure has been well-hidden by the fact that they have a monopoly product that is a cash machine requiring low/zero marginal investment...once you start from that premise, you realise that management has destroyed monumental amounts of capital (your comparison with university is very apt, Google is functionally a bureaucracy operating like a 11th century monastery, you have to spend years studying pointless trivia to get in, a totally institutional mindset).
At least in my experience the main difference between exams and interviews comes down to relevance. That is, an exam will be within the context of material you've been studying and an interview just... kinda whatever? I have only very, very rarely seen -- from both sides of the table -- professional interviews that are associated with the job the person might do. This problem is worse the larger the company, once there's a standardized set of questions to evaluate someone's possible fitness for a variety of roles.
When I've had power over the interviewing process it's always been enlightening to ask the interviewer to take their own interview. I'd be willing to bet most professors can pass their own exams; the same hasn't been true of interviewers.
Everyone at a university is taking the same test with the same expectations, usually to some national or international standard for that field of study. Each FAANG has their own set of tests that are not standard or internally consistent, even for the same job.
This is the cost of fighting professional standards for the industry as a whole. I'm not necessarily for that, but I don't know what the sensible alternative is to inter-corporate pissing matches and job titles that are practically meaningless. Nobody who knows how to build a house or fix a car is going to spend months playing puzzle games about those topics. They are just going to find an opportunity to do the work they enjoy somewhere else.
I always wonder the same thing... either an interview process is so brutal that they would end up not hiring anybody (so they'd eventually relax it), or it's just the "right" amount of brutal, and people who are complaining about it are experiencing a bit of sour grapes. And don't get me wrong, I've interviewed for jobs and felt lousy about getting rejected and tried to convince myself that it was "their loss" even though it was a job I really wanted at the time.
On the other hand, I get the sense from people who've been through the Google treadmill that the problem isn't so much that it's hard like university courses are/can be but that it's arbitrary.
With brush tests you might easily end up hiring someone who excels at your tests and nothing else. Overfitting can be a problem even with subjects that don't actively try to adapt, and for Google they most certainly do (I read the "please take some months to prepare" suggestions as a clear indication that they want a level playing field wrt adaption, kind of cheap to leave that problem to be solved applicants)
In the long run you might end up with better results if you don't even try to identify the one optional choice and only focus on weeding out false positives, leaving the rest to a diceroll.
(I'd be surprised if what happens at Google wasn't a weird compromise Frankenstein of both)
Most interviews these days ape off Google interviews too. See most FAANG-style companies. Very few deviate from coding or systems design questions. Thus if you're studying for one, you're kind of studying for all.
I never hear reasonable alternatives to this. Surely you'd rather a coding exercise than a take home coding practice you never feel will be complete enough for people. Or to do what Basecamp does and work for 2 months only to be given the boot.
I would see university admissions as a closer comparison than university tests. If I'm applying to jobs (or universities) I'll want to apply to several in case some don't accept me, some feel like a bad fit once I'm in the process, etc. I won't want to cram for each. I'll want to reuse the same cover letter or admissions essay to the extent possible.
Once I'm in the university and enrolled in classes, I'll know what to focus on and I'll be willing to study hard for tests.
I know some people see it differently, but I've always considered multiple potential employers simultaneously and I definitely haven't been willing to play the "devote weeks of your life to try to get hired by a specific company" game. On the other hand, some people find that worthwhile, and more power to them.
Three years ago I interviewed at Google for an internship here were all the steps I completed:
- Google Foobar to get someone to notice my resume
- First form that asked for general information
- Second form that asked weird behaviour questions like "Do you think people can change"
- First interview with regular leetcode questions
- Second interview was waved because of foobar
- Third form to write your interests/motivation for matchup with a team (No guarantee of having an internship at that point)
- Dropped the whole process because I got an offer somewhere else
The whole process spanned maybe 3 months.
The year after that I re-did the whole process and was ghosted by the recruiter after the first interview, I assume that was because I did not rank high enough and they were waiting to see if I'd make the cut or not.
This process (and the big version for FTE) works to weed-out candidates that aren't motivated to work at Google and I just don't see how else they could be doing it. People have to understand that recruitment at FANG is painful because you will get thousands of SDE applications and you can't really take the time to treat everyone "right".
> It was the design of the recruiting system itself that became his problem: At some point, Google decided Watt (who was working as an associate professor at the time) was interviewing to be a site reliability engineer, despite never indicating an interest in that role himself (he was interested in a more management-focused position).
> "It just never seemed to get through. They were so focused on whatever categorization they had chosen and it was fixed," he said. "I think something in their processes meant they weren't really looking for a fit between a person and a job. It felt to me that they probably had a recruiter who was looking for a certain role. Once they put you in the pipeline, that's the role you're in."
Didn't Google at some point decide a guy who developed a VM or interpreter or something that they were using in-house was only good enough to be a sysadmin for them?
> Didn't Google at some point decide a guy who developed a VM or interpreter or something that they were using in-house was only good enough to be a sysadmin for them?
You're probably thinking of Max Howell, the maker of the Homebrew package manager.
>> Didn't Google at some point decide a guy who developed a VM or interpreter or something that they were using in-house was only good enough to be a sysadmin for them?
> You're probably thinking of Max Howell, the maker of the Homebrew package manager.
My memory is very fallible, but I don't think that's it. I'm sure there are several similar incidents, and the one I'm thinking of definitely involved a sysadmin role and maybe even an offer. The issue was that the role was an insultingly bad fit, not that a talented person got rejected.
Yeah, at least in the past it was pretty standard for them to assign you a seemingly random interview gauntlet focused on a role that wasn't a fit for you and wasn't even the one you were applying for.
I interviewed for javascript vm/browser runtime stuff multiple times and until the last interview cycle I kept getting assigned to interview with people who worked on android apps or cloud storage infrastructure. Complete mismatch. I don't write Java, dude.
Google routinely makes offers to people only for SRE roles even if they want another. It happened to me in 2006 and it sounds like not much changed.
SRE is an odd department inside Google because they want people with an unusually wide mix of skills. They want a lot of people who are software developers and have those skills but who also have networking, UNIX sysadmin and maths skills. The requirements and interviews are/were more intense than for regular SWE roles. My interviewers tested all of those and more. At the end even if you just want to write software you get an offer that boils down to "it's SRE or nothing" because frankly, not that many people want to do SRE work, so they have to be a bit muscular about it. Normally they point out that after a year or two you can transfer if your job performance is good enough, which is what I did.
Anyway this Watt guy sounds like he's blaming Google for not giving him a free choice of roles. That's not a demand made of any normal company. Usually it's understood that companies have particular needs and are looking to fill them.
When I last interviewed they sent out a huge pile of PDFs that said "think out loud" and "explain your thought process". During the interview, I explained every solution I'm not considering and why. The interviewers appear to have interpret this as 'candidate thought this would be a possible solution' and kept steering me back to the optimal solution, which I was on my way to explaining. This resulted in interview feedback that I needed some guidance.
The kind of folks that can plow through hacker rank etc want to show everyone how good they are, even candidates. Google's process may result in selecting good SWEs, but it also selects for bad interviewers.
> When I last interviewed they sent out a huge pile of PDFs that said "think out loud" and "explain your thought process"
I hated those type of interviews when I used to interview (as an interviewee) for programming positions. I am the kind of person that cannot multitask at all: I sometimes even have to close my eyes when I am thinking something before saying it.
Nowadays I am on the other side being the interviewer for programming positions. I make it really clear at the beginning of the coding part: Feel free to shut up and think, focus on writing the code you'll write, and we will talk about it once you have finished.
Before finally getting hired there I interviewed with Google at least 3 times (hard to remember), on a referral each time (for a different team, from a different person). Incidentally, doing an interview for any role puts you on a secret 6+ month lockout, so it turns out that if you're interested in working at Google you shouldn't interview unless you're absolutely sure you want that role and can ace the interview. Anyway,
Each time until my last interview cycle, they seemingly assigned me interviewers at random and they were usually a terrible fit. I'm a games/systems programmer, so think C, C++, C#, etc. Console games (PS4), PC games, etc. Never shipped a mobile app, don't have much Linux expertise, don't list them on my resume. Haven't written Java since the J2ME era.
So naturally, I kept getting assigned to interview with people who worked on the Android Play Music app, or people who wrote Linux cloud storage infrastructure (think talking to storage hardware directly, etc) in Python and C. Inevitably, it was impossible for us to have an in-depth technical conversation without a lot of overhead because the disconnect was too big. Sometimes they'd ask me to whiteboard and there was no appropriate language for me to use that we both understood. At the end of each day I came away having had interesting conversations with people but it was consistently a failure of an interview process, so it wasn't a surprise that they never made me an offer. You could tell that this messed up interview process was also an issue for interviewers - I had a couple different interviewers get really combative or frustrated because of the disconnect, in one case borderline abusive.
Then finally a team that really wanted me (the NaCL/WebAssembly team) looked at my interview history and just stacked the deck so that everyone interviewing me was actually qualified to interview me. It was a breeze. Sure, it was challenging like any good interview, but not a complete waste of anyone's time.
While I can't speak to this personally, I also have heard from current/former Googlers that in the past it was extremely hard to hire Linux experts (kernel devs, etc) because they kept giving those people the same garbage screen (let's talk about Java!) and then rejecting them in the same way. Apparently the fix was a special interviewing process for people like that, presumably that's the treatment I got eventually.
This was the same for me. I'm an engine / graphics programmer with experience on console, looking for work after the studio I was at shut down. Google decided to match me up with a team working on an Android app, because it was "Graphics", and it resulted in maybe the worst phone call I've ever had in my life: any time I asked about technical questions, they just said they didn't have to worry about that part since they were using stock Google libraries. They were working on a application that displayed 3D models, so I asked about their art pipeline, which elicited the answer "what's an art pipeline, I've never heard that term before" from the project manager. It was clear that my skills weren't valued, and at times it seemed like they didn't even want any additional team members.
None of the people who interviewed me are still at Google.
I recently went through a similar experience interviewing at the Director level with Amazon Advertising, nearly two months of time-consuming and exhausting interviews, just to get shut down on a minor (minor minor) technicality.
Cool, man. Now I work for a major global agency pulling about the same compensation, and we won't recommend Amazon Ads for our clients b/c the product is well-known to be shit.
I think the website is just broken. For me theres a menu overlapping like 80% of the screen vertically, and the light gray text is illegible on a white background (edit- screenshot here https://i.ibb.co/6YsVmQ4/Screenshot-20211008-113929.png). I know HN discourages complaints about an article's web design, but yeesh
Google's recruiting system isn't "failing" unless they're hiring unqualified devs.
Google gets tons of applicants. The point isn't to prevent qualified applicants from being rejected, it's to prevent unqualified applicants from being hired.
They can do whatever arbitrary, unfair filters they want as long as they still have at least some applicants left, and as long as those people are adequate.
If your teams desperately need qualified staff to get things across the finish line and you can't hire them, your recruiting system is failing. This is a real problem Google has had in the past (I don't know if they've fixed it since I left.)
That is the main feature of the recruiting system, the whole reason they do it is so that managers can't circumvent the standard process no matter what.
It might lead to some problems you don't have in the old nepotism ridden systems, but it also solves many of the problems the old systems created. So you can't say it is failing just because it doesn't do everything right.
I agree in part, but they are failing if their system is imitated by everyone else.
Every time there is a thread on HN where people are debating the right way to filter applicants, the premise that goes unexamined is that there is one optimum, whether it's Google's procedures or something else.
But it's not just Google that can't hire everyone qualified. It's every employer.
Say, for simplicity, that any employer is only able to hire 1% of their applicants.
If they all used some optimal procedure, then they will all be fighting over the same 1% and the other 99% will be unhireable and start a revolution or something.
This is inescapable, I think, no matter what the so-called optimum is. It's like...a Doomsday Schelling Point.
Each company can disregard the fate of those filtered out, but only if their methods are sufficiently diverse.
They could be hiring unqualified developers, there's nothing that can determine with certainty that the ones they are hiring are any more qualified than the ones that fail for arbitrary reasons, or are simply unable to hire more qualified people because nobody really good wants to put up with the pointless gantlet.
Or, they could be hiring developers that, although qualified by the standards of the hiring process, are in fact unsuited to implement things Google needs to retain customers and stay profitable, but that's something we'll find out later.
In either case, the assertion that the system is correctly separating the qualified from the unqualified is unproven.
I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed.
Well why the hell not?
The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again.
I didn't happen to know that particular detail at the time. It derailed the entire interview. He was fixated on this one very specific piece of knowledge. And the worst part is not only does his approach make your code less clear, there are also contexts under which it wouldn't work.
I don't know if that particular interview was the reason for my not being offered a job.
I did end up hearing later on about hiring from a couple of Google engineers at a tech conference. They said that it is quite common that Google makes you interview two or three times.
I suspect the reason is to make you feel a sense of gratitude for being hired. And so you don't quit.