To be fair, the bit of juiced up kick to the brain doing a leet code problem on the train commuting to work has made me feel much more engaged once I show up.
> Your interviewers try to understand what it feels like to work with you on a daily basis.
If that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is?
I'd actually argue that for many companies this post is true (i.e. that getting it "right" is less important than the journey) but I still won't forgive companies that design the most hostile interview questions possible, and are then surprised when interviewees complain.
You can read the types of questions Google asks here:
I'd never interview at Google or any other company that operates this way. If the very first interaction I'm going to have is off-topic trivia, we're done, the company failed MY interview. The questions Google asks are disrespectful and unprofessional.
But disrespectful and unprofessional interview questions ("why are manhole covers round?") has become the new normal in this field.
To me OP seems to assume a competent, unbiased, and well meaning interviewer: always giving hints, knows exactly what they want, will field and answer questions comprehensively. At Google's scale with hundreds of thousands of interviews on the books, thousands of interviewers who like all human beings have good days, sick days, angry days, and depressed days, this will not always happen. What happens when its the interviewer trying to have a "smartness" contest? There are too many testimonials of this happening at Google to just ignore it.
I agree 100%, there are too many testimonials about people asking about things like linux syscalls and the different bits in TCP headers for me to believe that all Google interviews are conducted without any tech pissing-contest shenanigans.
What happens is the hiring committee will disregard the interview report, and send feedback to the interviewer, saying "don't do that". (There are generally 4-6 interviewers on an interview panel, so if one interviewer does a bad job, there are other interviewers who will be providing signal to the hiring committee. A single bad interview report won't sink a candidate.)
Google's interview training is pretty specific about what is expected of an interviewer, and the interviewer has to write up fairly comprehensive reports about the questions that were asked, and how the candidate answers them, what hints were given, etc. Most interviewers ask questions that they have asked multiple times before, so they will include things like, "The candidate (TC) took twice as long to code this a very basic warmup question that was designed to motivate a more in-depth distributed computing question; unfortuantely, what a strong candidate could do in ten minutes, TC couldn't get working C code in 45 minutes". (Current best practice is to try to avoid revealing the gender of the candidate in the interview notes, hence the use of TC instead of he or she. The goal is to try to avoid triggering any unconscious bias on the part of the members of the hiring committee.)
Now, there are some screening questions that are asked by recruiters as part of an initial phone screen when they are hiring for SRE candidates. Those questions are multiple choice and are really basic questions designed to screen out old-school operators who are quite good at mounting tapes (for example) but don't have any understanding of what TCP might be, and who think an SRE job is no different from a traditional system administrator position. Those are not asked by an engineer, but by a recruiter; the goal is to avoid wasting everybody's time.
I'm not sure what you are asking. Each interviewer on the interview panel writes up a large amount of notes on their interview. The C++/Java/C/Python code written by the interviewee, what hints were given, what blind alleys the candidate might have wandered by, how the candidate tested the code, how long did it take for candidate to find a bug (with or without hints, etc.)
For a design question, the interviewer will write up a sketch of the design, what tradeoffs were identified by the interviewee; what hints, if any, were needed, etc.
Then the interviewer will rate candidate on various technical dimensions (coding efficiency, design, etc.) and non-technical dimensions (communication, leadership, etc.) For each of these ratings the interviewer has to justify the rating, by pointing at examples from the interview notes.
Finally, the interviewer will be asked to score the candidate along a dimension of "strong hire" to "strong no-hire" and again, the score must be justified with a paragraph. For people on the hiring committee, the justification for the scores are often far more important than the actual rating given by the interviewer.
The hire/no-hire decision is not up to the interviewers; the hiring committee is composed of a different panel of engineers who review the interview reports from the interview panel; and the members of the interview panel write their interview reports without getting to see or hear from the other members of the interview panel.
Every interviewer provides a lengthy write-up of each interview: several pages of notes, including the raw notes of what the candidate said, questions asked, plus an evaluation against a rubric for a number of criteria.
The system is not perfect (what system is?) but as someone who has conducted tens of interviews as a Googler and at other tech companies, I can say it's one of the most rigorous and fairest systems I've seen so far. Interviewers are trained to try and get candidates to a 'win', trained to be aware of their unconscious biases, and the hiring committee process reduces the significance of any one vote. In general, the process is designed to select the best candidates and give all candidates a positive experience.
It's not perfect -- indeed, I'm sure I've given 'failing-grade' interviews as an interviewer here and there -- but it's one of the least-worst human systems that I've encountered, from both sides of the process.
Can you imagine how much effort you'd need to fabricate a convincing account of you asking reasonable questions, after you assaulted the candidate with ego-tripping trivia questions...
Besides being wrong and pathetic, why would anybody want to do that? The goal of maybe 90% of Google engineers is to spend as little time as the company allows on interviewing and writing feedbacks, and instead spend time on actually working on their projects.
Asking a question well takes skill. It is possible that an interviewer screwed up asking the question rather than that the candidate screwed up.
Most interview systems don't have a systematic, ongoing way for accounting for this especially given that interviewers are self reporting.
In my opinion, most interviewers are undertrained/underskilled at asking specific questions and at interviewing in general. They don't invest the resources to systematically improve but rather treat interviewing as a burden to be minimized.
There is still a lot play in systems that allow for borderline smart ass behavior. Do you think an interviewer will write up that they sneered at the candidate?
The interview process is a factory. The company is mostly concerned with reaching outputs. The candidate is just a happenstance casualty.
It’s almost as if interviewers need to be tested as well. An interviewing contest where a faux candidate rates interviewers and suggests area for improvement.
Of course, that would be rediculously expensive, so at best some canned training is used instead. Still, it might make sense for higher value teams.
At Google, responses are calibrated against other interviews that interviewer has done. If they have some consistent skew then this can be adjusted for. If the interviewer sucks and the committee can tell then they can give that score less weight.
After interviewers are trained, they will perform at least two "shadow" interviews where they tag along an experienced interviewer and they want the interviewer conduct the interview and then are asked to write up an interview report. After they finish writing the report, they can see what the experienced interviewer wrote up, so they can understand how the writeup should be done.
Afterwards, the new interviewer has to do a non-trivial number of interviews before they are considered "calibrated". When an interviewer is uncalibrated, their score won't be given much weight, and the hiring committee can see how their interview reports and scores compare against more experienced interviewers. This also gives an opportunity for the hiring committee to send interview feedback (e.g., you're asking a banned question; the coding question is too simple, so it's not providing enough of a useful signal; don't ask "trick questions" which again don't provide much useful signal whether or not the candidate can answer it correctly, etc.)
So there is certainly ways in which interviewers do get suggestions for improvement. And it doesn't have to be _that_ expensive. It's just a matter of making sure you don't have more than one uncalibrated interviewer per panel.
It won't be possible to extract any useful information from such interviews. But I guess it's possible to convince employees to haze candidates this way. You should feel bad for doing this to people though.
>It won't be possible to extract any useful information from such interviews. But I guess it's possible to convince employees to haze candidates this way. You should feel bad for doing this to people though.
Empirically this isn't the case. It would be much more interesting if you took the time to elaborate on what about this process is cultish, why it won't provide useful signal. Without that, it just comes across as a mean-spirited complaint.
Why are manhole covers round, and similar brainteaser questions have been banned at Google for ~5 years at least. They're only the new normal if you're a decade behind the curve.
My link from Glassdoor has feedback from interviewees from as recently as days ago. You can see the types of interview questions Google is asking right now.
The sentence you're referring to was in the context of the FIELD which is why it said as much, and the specific question is a very well known stereotypical example:
> But disrespectful and unprofessional interview questions ("why are manhole covers round?") has become the new normal in this field.
If you browse my link you'll see that Google continues to ask off-topic questions, even if they aren't riddles or brainteasers.
Why don't they ask questions relating to the job? Why don't they do practice tasks that you'd be expected to do on the job? Those are the core issues.
> Why don't they ask questions relating to the job?
When I hear of this sort of behaviour in interviews, I have to assume that the culture of the dept is such that x% of your job will entail fielding issues that are things that you consider outside your 'job'. If 20% of the time you'll be talking about stuff that you consider tangential, and you don't react well to that, you may self-select out. ?
But it’s not anymore. For all we know it was just a single early downvote, but your comment criticised the whole community. The guidelines ask us not to make comments about downvoting, as they make for boring, shitty discussions like this, and because a downvoted state on a comment is often temporary, whereas a discussion about it is permanent.
"If you browse my link you'll see that Google continues to ask off-topic questions, even if they aren't riddles or brainteasers.
"
I have read literally thousands of interviews at Google (both on hiring committees for 10+ years and in the group that reviews hiring committee decisions), and i just don't encounter them much.
I can't even remember the last time i read this type of question.
I suspect your definition may be different than mine.
I do see that new grads/folks without a ton of experience get asked more questions to test fundamentals (not riddles), and folks otherwise get asked to just solve problems.
I have also seen occasional a few unscored warmup questions that are more abstract/riddlish for nervous people, but even that's pretty uncommon.
It's usually small talk about resume instead.
Interviewers are also deliberately pushed to ask different questions if the candidate is not doing well (though it's slow to change interviewing behavior on this). Rather have signal on more questions than knowing that they really did badly on a single thing.
That means they may change style/abstractness of question depending on how interviewee is doing.
The problem is off topic questions, especially for more senior developers who have specialized extensively. For example, I haven’t used or seen used dynamic programming since college because my area doesn’t really use it. If I didn’t cram in interview prep for these questions, I’d be toast.
I wish programmers were treated more like designers with a portfolio review. I’ve implemented so many cool things, yet somehow I’m judged based on some esoteric programming problem. It’s like I’m an interchangeable cog who is being evaluated on how well I can be a cog....heck, HR and often even interviewers often don’t bother looking at your CV. Dammit, I do compilers, not chatbots!
The really great jobs I’ve had didn’t really require interviews at all, they knew who I was and knew what I’ve done and what I could do, and that was good enough.
See comment from gedy elsewhere in the thread. Multiple people have pointed out these kinds of questions being asked well past 2006.
Since there is no incentive for a large number of engineers to cook up stories about their interview experience at Google, I am calling this smoke as having some fire behind it.
I've certainly met people who believed that anything other than (for example) an android ui question with open book stack exchange was a dumb brainteaser with no relevance to the actual job...
For my part, about every few months I hit something that would make a great interview question, and then have a wonderful afternoon coding it up... Ymmv.
But what's the incentive for a large number of Google engineers to surreptitiously ask questions of a style that's explicitly banned?
I think there is incentive for failed interviewees to cook up stories - or at least to tell something very one-sided - because none of us like to believe we failed at something and feel better if we persuade ourselves it was stacked against us.
And in fact there's no need for explicit animosity by the failed interviewee. Someone who misunderstands a question badly enough to call it a brainteaser when it isn't is also likely to have performed badly on it.
The most persistent critique I have heard about Google is that the experience can be very uneven in everything from recruitment and workload to even salary for the same job. Even if Google entirely stopped with brain teasers, people certainly seemed to have expected them on account of unpredictability up until a few years ago.
The incentive is just not having to come up with and calibrate new questions. It takes a lot of effort to do that, and if you've been asking a "banned" question for a while and are comfortable with it, it's easy to just keep using it until someone explicitly tells you not to (reverse feedback from hiring committee to interviewer wasn't a thing for a while). Most engineers don't really enjoy interviewing and want to put minimal effort into it.
I have a much higher faith in the capacity of the Internet to produce liars, trolls and delusionals than you apparently have.
This is an open internet forum for anyone to type anything they feel like in. Of course, as far as you know, I might be an Uzbeki 12-year old, so that argument only goes so far...
I can imagine that Google interviews for other roles than Software Engineers can have any kind of wacky questions. But mostly these stories sound so much like the stories that used to go around about Microsoft interviewing, only with the company name switched, that I have to think it has to do with their inherent virality somehow.
I can confirm that no one asked me a brainteaser or gotcha question. They did, however, ask me irrelevant questions. My system design question involved a web based system. I am an embedded guy with no web experience who was interviewing for an embedded job. I would have been happy to design something in or near my skillset, but I have rarely worked with load balancers, backends, schemas, etc. I did my best and tried to have fun with it, but my interviewer was clearly not amused and seemed slightly annoyed that I didn't know anything about his domain. I was given preparation materials which did not mention anything about web architecture or design, only things relevant to my skills.
The opposite happened to me at triplebyte. There was a whole section on embedded systems and C. My interviewer let me know the section was coming up and I asked if I could just say "I know nothing about embedded systems or C" so we could just explore my web dev knowledge further, but no go. Very weird. I have nothing about either on my resume, and no desire to target any jobs that need me programming anything other than webapps in JavaScript for at least the first couple months...
Triplebyte is supposed to be resume-neutral, so it is reasonable they would try to ask you about it. Surprising they didn't take your word for "I know nothing about embedded systems or C" though... Maybe the interviewer has to go through the motions of asking you everything so that Triplebyte has a complete profile on everyone's performance on every question for their internal data analyses.
> If that were true then why not simulate those situations
Because when you try to simulate those situations in an interview that needs to be conducted in 45 - 60 minutes, the questions become the kind you hate.
I regularly interview candidates; and some find my questions weird. The point is that I'm trying to simulate everything in such a short time. Otherwise, each interview would take 16-32 hours, because we'd have to go through a massive onboarding process just to ask basic questions.
>If that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is?
I hate this meme so much. I personally have seen situations in my own work several times in the last few months where knowledge of algorithms, even on the leetcode medium level, was immensely helpful in finishing the job. If you can do it quicker and more fluently, you're probably going to be more productive.
I remember that there are test patterns built into T1 CSU/DSUs, but not what they are or how to turn them on -- if I need to know, I'll look it up.
I remember that there are three QoS bits in the IPv4 header, but not where they are. Probably pretty early, because of hardware implementations.
I remember that lots of people look down on Perl 5's object system, but not why. I remember the existence and purpose of lots of Perl modules, but not the interfaces.
I edit JSON and YAML every few weeks, but I don't have a conscious recollection of the rules -- they're prompted by looking at what's already there.
I can guesstimate Big-O notation on most chunks of code, but I'll be fooled when there's a function that's hidden in a library because I generally don't have those memorized.
I can tell you the bandwidth of lots of hardware interfaces, and the relative efficiency of speed and efficiency of storage for a handful of RAID configurations -- the ones that I set up, and the ones that I avoid.
I know one firewall configuration tool reasonably well, which means that I look up esoteric bits, and have used so many that I expect to do common things in all of them with a quick examination of the language.
I currently know a fair amount about GDPR and why it doesn't apply to my company (and how we can assist customers with their GDPR requirements) and lots about the Massachusetts and Virginia data privacy law. Very little about PCI compliance, but my point is: if my company wanted to do card transactions, I can figure out what I will need to learn to write a good policy and get it implemented in a way that won't embarass anyone.
In short: when the job is the same thing over and over again, you memorize the details. When it's always something new, you need a broad overview about what can be done and where to find the details.
5-6 years ago, I went for an interview in a real estate company. The introductions lasted all of 2 mins. Then they took me to a computer, showed me a bug in the code base that I would be working on, if I got hired. Then they said "please fix this". Took me about half hour or so to hunt the bug down and fix (it wasn't hard, but it wasn't a cosmetic bug either). Then they asked me how I found the bug. I explained, they told me I'm hired, and the paperwork will follow in a day or two. No other questions were asked, they didn't look at the resume at all.
The entire experience lasted less than an hour - from the time I walked into the reception till I walked out. Best job interview ever!
This codebase was probably 0.0000001% as complex compared to Google's (I can only imagine). Still, there is no reason more companies can't follow this style, at least for one of the several "rounds" of interviews, instead of whiteboard, trivia etc.
I gave 4 examples of this in an above comment. Yes, it happens. Yes, its wrong. No, people and companies don't care.
At the end of the day, this is what sucked the optimism out of me at my previous company. We had lots of people trying to steal from us. Even after I closed it down, I had two people in particular, ask me to help them design something, or give them detail domain/design knowledge, for free.
Yes, it happens. Far too often. Makes people like me jaded.
How is this useful? The interviewer still needs to evaluate the code and conduct the follow-through questionnaire. They could just spend that time fixing the bug instead.
That would be hilarious. Most of the value of a developer doesn’t straight out come from the code they wrote, but everything around that (design, maintenance, hardening). Getting free code isn’t actually that helpful without a lot of other stuff around it.
Not that you are wrong, but you are underestimating the dumb assholes who assume they would be cruising right on path only if someone could solve this tiny niggling problem for them.
I had to tell one moron on phone interview that they are looking for free consulting or what because they keep harping a very specific project (Java/xml etc) setting that they were struggling with. It could of course be solved in hour or so by closely looking at product documents instead of endless googling.
I think you misunderstand the definition of hilarious. This is not an attack, but an observation.
When you are the guy who has to meet payroll for your team, and some (insert appropriate NSFW description here) person/company deprives you of pay for the work they are taking advantage of to further their goals ... think how that makes you feel.
There are many adjectives. None of them are synonymous with hilarious.
I had this happen in a previous life, when I was working on designing/building/selling HPC and storage systems. Two of the worst offenders were universities, one was a prop-shop, one a semiconductor processing firm.
One uni called me up to tell me they liked my bid, but they wanted me to teach another company how to to what we could do, so they could buy from the other company.
The second uni issued an RFP, required that they get to keep all the docs, including detailed design specs. After interviewing all the companies, mine included, they selected 2 finalists, us and someone else. They probed us hard for details. Wound up buying our design from the other guys.
The prop shop did a similar thing, though we won the RFP. But then custy went silent while working on PO. They then awarded it to our competitor, as long as they used our design.
The semiconductor firm had a problem they claimed they could solve internally (they couldn't), and wanted to see what we could do. We met all of their (aggressive) performance, capacity objectives. But they kept pumping us for "free work" with the promise of a very large contract later. Against my business partner's recommendation, I called them on it, indicating that we'd be happy to work on the project with them. But not for free. So they "fired" us, as in asked us to stop working on it. Now, 4 years later, they are still struggling with the task.
These seem to be contract negotiations rather than tech interviews, and you learned important lessons about protecting yourself from unscrupulous actors in the process.
> they wanted me to teach another company how to to what we could do
Here one might triple? their rate for a much shorter hourly design contract and leave implementation to someone else. The other two examples might have creative solutions as well.
My last company was accused of this constantly. We would ask a very contrived, simplistic problem that was themed along with the domain of our business. Most good candidates would know this and solve it quickly. Many awful candidates would accuse us of using candidates for "free labor," and threaten to report us to whatever agency they think deals with this sort of thing.
I've seen this accusation thrown around dozens of times. I'm convinced that it's not really an actual issue, and just another way for bad candidates to transfer blame elsewhere.
I don't know if you are joking or serious. How much work do you think you can extract out of a normal developer in an hour or less, especially when he/she hasn't seen the codebase before? And how much effort do you think it would take to schedule the interview in the first place, starting with posting an ad, then screening resumes, scheduling time...? Not to mention someone has to vet/test the bug fix ...
This doesn't seem reasonable to me at all.
On the other hand, I can believe if this happens with those "take home assignments". Those tend to be larger (few hours to a few days) amount of work.
BTW, at least in this case, I did get the offer as they promised, within 48 hours. So I don't think they were doing anything shady. My guess is that they simply got tired of normal style interviewing and found this to be an efficient way to hire.
My current company does this. But instead of leaving the interviewee on their own, we do it as a pair programming session where they are the brain and the interviewer is the hands implementing it. Gives you a sense of how they think and a better look into how they work day to day.
Netflix hired me in a similar fashion. I would also characterize it as the "best interview ever".
I had a two-hour session with senior tech leads solely about solving a specific severe scalability issue in one of their database systems that they had not made much progress on. I showed them how I'd solve it using a technique unfamiliar to them. Next day, I get a "when do you want to start?" call -- they tried my proposed solution in a test environment and it had worked as advertised.
Two hours solving one real-world design problem in my area of expertise. Simple and on point, without any trace of culture fit, leet code, random whiteboarding puzzles, etc.
> As compared to say "are you going to have kids - to a woman"
That's not only disrespectful and unprofessional but potentially also illegal. But it isn't a contest to see who can be the most disrespectful or the most disrespected, so I don't follow your point.
That is definitely her personal opinion, as she is not a spokesperson for Google as far as hiring is concerned. Neither am I.
However, I think if you ask people who conduct software engineer interviews at Google, a lot of them will agree with her opinion, including myself. One thing I would add, is that there is unfortunately no strong consensus on what to expect from the candidate, so variance seems to be high. That is why candidates are encouraged to try again, if unsuccessful.
I've had Google recruiters reach out to me multiple times over the years and I've never taken them up on an interview. This last time, I told the recruiter I just wasn't interested in going through the process, and his response was a shocked "but why??" Is it so shocking that I don't want to subject myself to grueling demoralizing interviews to likely be rejected? I can get good work, with people I know, making good money, without going through any of that. I'm not interested in the Google Hazing.
I had a google recruiter reach out a couple years back, and I asked for just some ballpark idea of salary range. No dice - they wouldn't discuss even a ballpark range until I'd flown and and given up a couple of days or my time for travel and interviews. I didn't followup.
you can google the salary range, its not too hard. protip: its pretty low unless you have competing offers then it can be a little larger than your largest competing.
Great. So if you have ~6 years experience they will quote you a range of 150k-220k for say L4-L6 when your TC (base+bonus+rsu) might be anywhere between 200K-575K[1].
That doesn't sound like a particularly useful answer.
Isn't that exactly what MTS ("Member of Technical Staff") and "slotting" were at google, at least up until around 2012? They hired people not knowing exactly where to level them, and after an introductory period, they were placed somewhere along L4 to L6.
I had to look this up because I'd never heard of it.
Slotting and MTS existed, but indeed hasn't been done since 2011 or 2012, and hadn't applied to L3 or L4 candidates for much longer, which means it likely was a way to differentiate between borderline L5 and L6 candidates or borderline L6 and L7.
> Is it so shocking that I don't want to subject myself to grueling demoralizing interviews to likely be rejected?
Yes, it is. And this is a problem bigger than Google, this is simply one of the things that are going wrong on this planet. It is however one of the problems that are _relatively_ easier to fix.
I'm not sure I follow. It's shocking because I should want go through a Google interview even though I have many other more interesting and just-as-lucrative options available to me? I'm not a stranger to taking risks and doing extremely difficult things, but Google has demonstrated to me, anecdotally through other talented and gifted interview candidates who failed, a high degree of randomness and subjectivity that is not proportionate to the difficulty of their interview process.
I was just reading a thread on Linkedin by a recruiter who lined up 30 candidates based on the client's requirements, only to have the client reject all 30 of them. This problem is rampant and I don't think anyone has a handle on it.
A few observations:
- Modern society is so captured by social media, it's easy to make shallow connections but when it comes time to make the deeper connection, an actual hiring decision, hiring managers simply balk, and Loss Aversion Bias takes over.
- Being able to apply via the Internet creates too big a pipeline and shifts burden to the companies, which don't have the resources to handle the screening workload in a way that shows any consideration for the candidate.
- The shifting nature of technology makes the recruiting business hard. How is the average newcomer to recruiting supposed to be savvy enough to suss out the 12 different ways someone can be a "Docker Expert?" It's just absurd.
- Everyone hates the status quo. Job candidates, hiring managers, people who work in the staffing industry all hate the status quo and wish for a better way to guide talent toward the places where it is needed.
I am not sure if this is in the interest of any company but why not provide feedback, as it can only help the interviewees in the future and the companies attract better talent.
Even if it's not standardized, a rubrik across X attributes with a scale and a number. (Which is what I am assuming they are doing anyway -- as it sounds likes the interviewers are rating them across different dimensions)
Not sure if this is some sort of a thing to do with liability but the interviewee can get generalized feedback.
Ex: Technical skills (2/5),Communication skills (4/5) etc. and they can improve on the relevant dimensions or compare notes with other companies / candidates as well.
Experience says that in addition to liability, failed candidates just try to argue and get upset. People claim they want feedback but then claim that the interviewer must have misjudged them.
More work for the company, and leads to even more negativity in the process.
I agree with the possible liability aspect but if they are doing it already, i.e. taking notes or rubric scoring, then it's just a matter of sending a summarized version of that and hopefully it's feedback from multiple people and not just one person's opinion.
The negativity may likely exist from no response/lack of feedback -- which can be frustrating for ppl that spent time/effort), but at least as the previous poster mentioned some people do appreciate feedback.
Also, recently noticed that companies have automated questionnaires asking how the recruiting process was or can be improved -- wondering if there's any improvements based on feedback.
As a side, it's been kinda interesting to read glassdoor responses for how people were treated/felt during the whole process (timing, professionalism etc...)
I meant to post this earlier but forgot to, sorry.
Yes, I can't remember where I came across the data, but providing feedback didn't actually increase interview satisfaction, but decreased it in the aggregate.
Candidates are prone to arguing and trying to nitpick the feedback to get reconsidered. It's counter intuitive, but that's what really happened.
I went through (and failed one part out of 3) onsite interview at Booking and afterwards they provided me a nice feedback with topics that I should strengthen. I totally agreed with the feedback as I felt I’m failing questions on those topics during the interview. Oh, and the recruiter even suggested to reapply when I strengthen those weak skills.
Why does everyone on HN seem to care so much about what Google does in interviews? We get it, no one likes weird off-topic brainteasers. Be a better engineer so you don't have to worry about having them on your resume and you'll be good.
"its not about the problem" but if you cant correctly code one of these 200 algorithms on a whiteboard in sub 15 minutes while under extreme stress youre not getting an offer either.
Because it's not a good measure of your programming skill. To be honest, I legit don't care whomst Google hires, what I hate is that there are all these other people who start adopting these attitudes and it can have a really shitty influence on the whole industry.
I don't think you need to worry about it. Google does interviews like this because they can afford to reject many good developers because they have much more candidates than they actually need to hire. I guess only most popular tech companies can do that. I bet it will never become a standard for the whole industry.
Because the people they hire can't do all the algorithms at interview speed either - they were just lucky to have reviewed the right material recently.
i just think its annoying because lots of companies cargo cult google and what thet do is a largely tangential skill set from the rigors of day to day programming work and knowledge. its a ritual from when they were hiring small numbers of graduate students with no real programming experience to measure them on. also the whiteboard is a relic of a time before there were laptops with hotswap 2nd screens.
ah yes i'm sure everyone is out there leisurely deriving from first principles their implementation of XYZ graph algorithm which happened to be useful in the course of solving said "open ended question"
speaking of misspresentation, i never said youre "asked" a pure algorithm question only that the timely implementation is a necessary component of succeeding
thanks for explaining how coding interviews work to me thou, really had no idea based on the 200 i've administered in recent years or dozens taken in my career.
You don’t get to actually run the code. They just let you type it in a google doc. I guess it’s not done universally, but it was when I interviewed there.
When I get interview feedback about literally not having a coded complete solution despite strong communication skills, understanding of the solution and underlying cs concepts, i really cant help but conclude this as nothing but PR...
Exactly. What interviewers are really looking for is speed and fluency in working through the solution. The easiest way to get there is by already having seen the problem. This leads directly to the “grind hundreds of leetcode” meme seen on Blind. (“LC and TC or GTFO,” in other words.)
Yet another "trust the system" message from the authority figure who enables the system. Similar:
- Police officer: Just follow our instructions, be cooperative.
- Car salesman: Just be upfront with what you want. Tell us about yourself, and we'll earnestly try to help you.
The message is the same; the authority "just wants to help," but in reality the relationship is adversarial to a larger degree than it is cooperative. On Blind, you know the real way to getting through the Google interview is LeetCoding like hell and not admitting you've seen the questions before.
I read it as "I'm trying to make sure I don't hire someone who isn't willing to work with me, and the system allows me to do that." I can't speak for anyone but myself obviously, but I think I interview at Uber a similar rate to your average Google engineer (2-3 times a week), and our interviewing process is pretty similar to what's laid out here.
In cases where the interviewer is hiring for their own team, I feel like it's reasonable to assume that the interviewer is trying to hire people they want to work with. Acting in their own self interests, as it were.
In some cases that may mean "I want to make sure you are someone I'm able to collaborate with." In some cases that may be "LeetCoding like hell". Regardless, if that's what the interviewer is looking for, the candidate gets a really important insight in to the team they'd be working for and not necessarily indicative of some larger corporate conspiracy.
Google engineers don't interview people they work with (except rare cases). Interview notes go through a committee, so your job as an interviewer is only to describe how things went with the candidate (as explained in this twitter thread).
FWIW, I went through the interview process and I actually really enjoyed it.
My attitude going in was that I was evaluating what it would be like to work there, and I treated the interviewer as a coworker solving a technical problem, where I was taking the lead.
The questions I got were pretty much exactly the sort of hing you see on LeetCode, but I hadn't seen any of the questions before. I know from studying for other technical exams that once you reach a certain number of practice problems, pattern recognition takes you a long way.
I had a similar experience at Facebook. Everybody was super nice, they all wanted you to do well, and they all responded well to being enthusiastic and genuinely interested in the problems you're solving.
> Everybody was super nice, they all wanted you to do well
I had the same experience. Afterwords I thought I did pretty well because I got to a solution to all the problems eventually.
Later when I discussed not getting the offer when a friend who works at Google. He said they try to guide the interviewee to a solution before the time limit. Which is reasonable, you want the interviewee to feel more confident and not get tilted by messing up just one question. However in hindsight the interview is a lot less enjoyable. You can't show any weakness solving a problem, less they offer you a "helpful hint" and record a black mark against you. The interviewer is there to smile and act like your colleague solving a problem while all the while making a list of why your a bad problem solver.
I'm not that bitter though. The interviewers that asked me questions actually related to the position I was interviewing (embedded software) did actually feel fun and collaborative. I accept that if I want to interview well at companies that employ these types of interview processes I will need to do every problem in CLRS (or at least more than zero).
I haven't been on the interviewing side, so I can't really comment on some of this.
But the impression I got as the interviewee was that every question ramped up in difficulty. The slope of the ramp-up depended on the question. So maybe in your case, you didn't get as far on the difficulty ladder as other people that were interviewed.
I was pretty shameless in asking for hints when I needed them, but it was typically of the form "I see this tradeoff here, and my gut says to do X, is that reasonable?" I'm sure some of that counted against me, but I was blunt about what I needed to make a decision and solve the problem, and I think overall that reflected well on my ability to problem solve on a team.
I would definitely not recommend doing every problem in CLRS. I would recommend doing just about every problem in Cracking the Code Interview (because they have nice answers), and then getting into a rhythm of doing LeetCode problems every day until the interview.
"I see this tradeoff here, and my gut says to do X, is that reasonable?"
YMMV with interviewer, but personally, this is the type of thing that gets positive feedback from me - someone who understands and explains the tradeoffs involved.
Also, fair warning: LC has its uses, but it is not the same as an interview.
Yes, ramping up in difficulty is certainly a thing.
In both my experience taking a Google interview and conducting a lot of interviews at my own company, I agree that a good question is open ended. For example "write memcpy" is trivial to get sometime working but can lead down many paths when discussing performance and computer architecture.
What gave me trouble, besides being rusty with algorithms, were some trade offs I would never make in the domain I'm familiar with. In my day job my microcontroller has 192KB of RAM, so limiting the amount of data collected to fit is important. I never get to the point where I have to worry about my simple algorithm not scaling to GB of data. Another odd idea was doing lots of speculative computation to reduce the latency of a system.
All of these algorithm things can be studied and after failing a couple of interviews you can start to understand what the interviewer is expecting and how to clarify assumptions.
I do question what sort of company you build if you screen for people who can write code on whiteboards. There is no giant mono-whiteboard where all the software engineers check in their code, so the interview process is not related to what people actually do for the job. On the other hand I have interviewed hundreds of people and I don’t feel like my questions do much better with the same one hour slot given to me by HR. The whole situation is inefficient for everyone.
Here’s the thing: patterns you will spot doing Leetcode problems are almost useless for anything else. The only purpose for working enough problems to see those patterns is to have more successful interviews.
But one interesting side effect of the interview process is that everybody at a place like Google or Facebook or Amazon has a non-trivial understanding of efficiency.
I personally think we'd be better off if there was more focus on these puzzles and less focus on 'cultural fit' - but that's just me.
If nothing else, interviewing is an important part of your working life. To get a competitive job, you are probably going to have to practice something. I personally can get a lot more excited about competing on puzzle solving abilities than competing on social skills or social protocols, even if those puzzles might not be used very often once I'm at work.
(I'm not saying algorithms are completely unrelated to the work we do- I'm saying that even if they were, i'd still prefer to be tested on puzzles than to be tested on social skills)
I mean, the subtext here is that we're all getting interviewed for jobs we don't know how to do. All companies have their own infrastructure and their own way of doing things; you can't hire people with experience on that companies codebase unless you want to limit yourself to ex-employees. So all companies are interviewing to try to figure out who could learn how to do the job in question, and that's... pretty difficult to do.
My experience at facebook was being told I could use any language, choosing the language my preferred project was implemented in... and then having the interviewer repeatedly and incorrectly argue with me about syntax trivia.
Not sure about Google but in IBM when I was conducting tech interviews I was looking more for team members to help me complete the project rather than trying to project an authority figure.
The relationship was never adversarial and if you know how desperate we were to get good skills there is not much option to take the high ground.
The poster is correct that open ended questions that reveals the work ethic of team members are much more important than solving algorithms and hard problems. Intelligence is over rated.
My (pre?) interview with Google was little more than trivia questions. Example: the numerical value of SIGTERM. I could have talked about signals and how they were used for 20 minutes, but a nontechnical phone interviewer just wanted trivia answers.
I want to think that’s a terrible question - checking whether they have the signal table memorized is a hilariously bad way of trying to assess someone’s fitness as an engineer.
On the other hand, there’s some signal (sorry) on the nature of the work you’re doing in whether SIGTERM (15) is imprinted in your brain from near-daily appearance on your screen, or not.
I don't think so, unless you are referring to some kind of atypical terminal work. I just tried killing a console program and I see "Terminated: 15". That's not a line I even recognise - it's not common or important enough to bring to my attention.
I would say a vital command-line skill is having a good filter to ignore what's irrelevant.
This is really absurd question to ask. Besides kill -s SIGTERM or even htop does the job. But like other commenters have pointed out the questions really depends on the person as there is no specific decided questions.
I sympathize with the general idea however this specific question isn't very representative of it.
Signals 9 and 15 and much more well known by their respective value than their symbolic name. They are everywhere in program output and log files and if those things are your daily work then you recognize this whether you want to or not.
It's like if you have touched computer code in any language then you probably know that 65 is A. Not because you have useless trivial memorized but just because it figures every time you look at string values for some reason. In one sense it is useless trivia, but on the other hand a programmer who never stumbled on ascii codes must have lived in an unusually insular bubble.
> Signals 9 and 15 and much more well known by their respective value than their symbolic name. They are everywhere in program output and log files
I have never written a program that outputs a signal number to stderr or a log file. And grepping the logs on a server with nearly 800 days of uptime, I can find only five references to signal 15, from months ago.
> It's like if you have touched computer code in any language then you probably know that 65 is A. [..] a programmer who never stumbled on ascii codes must have lived in an unusually insular bubble.
20 years of programming and doing things like making custom fonts. I couldn't remember the ascii code of 'A'.
The non-technical recruiter needs these trivia questions because they need questions with single answers that allows them to separate people with no technical knowledge and people with technical knowledge. The easy way to get past this barrier is to get a referral, then you start at the technical interview.
When I was at Google, I worked in a tiny office, and I was friends with the recruiter who worked that office. A couple of times she asked me to vet the answers to the non-technical questions, because if the candidate went off-script in any way, she simply couldn't tell if it's a wrong answer or a more in-depth answer than the script anticipated. This wasn't part of my job, and if our office wasn't so tiny we wouldn't have had any contact, and she wouldn't have had any engineers to ask.
Recruiters ask horrible questions. If the recruiter has to ask you a technical question, it will be a bad question, because the recruiter doesn't have the expertise to understand the answer.
So you're left with bad questions which have single answers, mostly involving rote memorization.
But the recruiters are told by the SRE team to ask questions like this to candidates before they get a phone interview. I don't see any value in that, but then I don't work as a Google SRE so I don't know what is important to them. It is also possible that they are lacking SRE interviewers so they need to ask stupid questions to get down the amount to reasonable levels.
Another thing that isn't transparent to outsiders is how frequently candidates are shopped around if it becomes obvious they aren't a great fit for the role they were recruited against. I can't tell you how many times I've been asked if I'm interested in candidates that started out as SRE, CE, PM, or other roles. As mentioned, recruiters are paid on hire rate, and it's in their interest to ensure that strong Google candidates are identified and presented to as many potential hiring managers as practical.
Additionally, it's common for interviewers to interview for multiple different groups (as an additional tech interviewer, a xfn interviewer, a Googleyness interviewer, etc), so exposure to job requirements can be reasonably broad at the interviewer level.
As I imagine many suspect, calibrating interviewers is hard, and always has been, for a company hiring roughly 10,000 people every year.
It was indeed an SRE question. Followed by a series of algorithmic complexity questions which I happened to get correct based on barely-informed guessing, having never taken an algorithms class.
Yeah, I call bullshit as well. Try getting to the onsite if you don't solve the phone screen question exactly as expected.
I have a friend who solved/memorized ~600 leetcode questions and got offers from Google, Facebook, etc. He was average, not dumb but not well above average. When I apply to both, I will definitely be leetcoding as many question as possible as well, to maximize my chances.
If that’s all it took maybe those interview funnels aren’t actually that great.
IME, my worst interview process ever was at Google. All I remember from it was some question about burning a piece of string. The coding part was relatively easy.
The best interview process I ever did was at Yahoo in 2008. Everyone was very friendly but the questions were tough. I found the “expert” level of the people interviewing me higher than at Google at the time. It was grueling though - 9am to 7pm. Got an offer to “join any team I wanted”. Turned it down for a startup.
You have two identical ropes. If you light a rope on fire, it will finish burning in exactly one hour. The burn rate is inconsistent - there is no relationship between how much of the rope has burned, and how much time has passed, until the rope has fully burned away.
How can you use the two ropes to measure 15 minutes?
Given that it's printed in cracking the coding interview, Google has almost certainly banned this problem.
> I have a friend who solved/memorized ~600 leetcode questions and got offers from Google, Facebook, etc.
Well then, to go through and solve 600 leetcode questions actually takes a lot of dedication and time investment, which alone to me shows that your friend has a lot going for him. TBH, as someone who has hired a lot of engineers, if I found someone who was well rehearsed, and it was clear this person understood a lot of the underlying concepts in a problem as I dug deeper, I'd be thrilled to hire that person!
Your examples aren’t particularly on point. You should (nearly) always do what police officers tell you because even if they’re wrong, the only thing you can do on the scene is make it worse for yourself, and your car salesman example is simply suggesting that you shouldn’t negotiate.
The fact is that Googles interview process isn’t designed to work for you or I, it’s desiged to work for them. The key factors that influence it are that they get tons of applicants, and they have a strong preference to eliminate false positives (which they can afford due to the previous point).
I’m not sure why somebody (seemingly earnestly) trying to help potential applicants understand the process should be the target of anti-authority criticism.
Some perspective from the interviewer's side may help here:
- A Google interviewer's (and I would assume any interviewer's) primary goal is to come out of the interview with enough confidence to give a positive or negative score. If they sit down to write feedback and have to give a neutral score, the interview wasn't productive. This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
- Doing interviews at Google is volunteer work. You are not interacting with a professional interviewer, you're interacting with someone whose day job is being an engineer. They don't have an evil agenda; they are doing this because they want to help Google hire the best candidates, and by inference make sure their future coworkers are good people to work with.
- Interviewers overwhelmingly _want_ their candidates to succeed. It's a true joy when I have a candidate who glides through a question (or finds a solution that was even better than mine). When candidates struggle, it's not a pleasant experience for the interviewer either.
- In the end, the point of technical interviews is to avoid the terrible experience that is working with an incompetent or uncooperative teammate. Interviewers are trying to find people that (a) can work well with others and (b) can get the work done.
- The system is _highly_ prejudiced towards suppressing false positives. This is the right decision, but it comes at the cost of a high rate of false negatives. Were myself or any of my colleagues to re-interview for our jobs, I would expect about a 60% hire rate. This is not even taking into account the constant ebb and flow of hiring demand. Sometimes there just isn't any headcount. And sometimes you just happen to get questions that you don't click with. This is also the reason that recruiters are so eager to bring you back to interview 6 months later.
- Recruiters and interviewers have very different incentives. Recruiters want to maximize the number of people they get hired; interviewers want to hire people they want to work with. This can lead to behavior that seems schizophrenic from the outside: the recruitment side of the pipeline constantly pestering people to interview, but once the candidate enters the interviewing pipeline the process is slow, deliberate, and careful.
I think that depends if you're talking about internal or external. At least everywhere I've worked our in house recruiters don't get paid a bonus when they hire someone, it just their job. If you're working with a recruiter that doesn't work for the company hiring you that person may have a more direct financial stake in your employment.
The engineers doing the interviews certainly have no financial incentives either way... Recruiters make contact and did a preliminary "do you have a pulse" conversation, and then shepherd the process, but don't have input into the decisions along the way. Their incentive is thus to find great candidates who they think will make it through the process.
This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
This is only true if the interviewer is uninterested in what happens after the hiring process. If they want to make sure they're winning a reputation doing great interviews for more good hires than bad hires then there's an incentive to be cautious, and that caution could well manifest as trying to catch out anyone who might be 'gaming' the interview process. Those false positives reflect badly on the interviewer; the false negatives don't because they might have been real negatives.
I don't think that interviews really generate reputation in a large company... First, multiple people interview each candidate, so credit/blame is always distributed. Second, and more important, ain't nobody got time for that.
Such a feedback loop -- of identifying which interviewers give the "most accurate" scores -- doesn't exist. Nor is it clear how you would build such a system (how do you quantify a "bad hire" or "good hire" in such a way that isn't lost in the noise?). Interviewers are trusted to do the best job they can.
Remember, interviewing is volunteer work, not something that will advance your career. The results of the interviews and committee deliberation are confidential, so there's no way to gain a reputation for being a "great interviewer".
Ah, but you are woefully naive if you think some interviewers don't slip in who enjoy having people struggle with problems so they can stroke their own ego. There are also the ones that have seen the quality of engineers significantly decline over the last 6 years of massive expansion and just want to gatekeep.
One of the major flaws in Google's process is assuming that the engineers are incentivized to find good hires.
It doesn't work that way. At Google, the only people who can see your ratings are the people directly involved in that candidate's hiring process. As a hiring manager, you do learn which of your reports/fellow interviewers take a tough line when scoring, but that doesn't make them great interviewers and doesn't factor at all at performance review time.
Source: I work & hire at Google. Opinions are my own.
Yes and No. You want to build your reputation as a good interviewer, but that doesn't only mean you are tough and let only amazing candidates pass.
That also means that you are usually aligned with the interview committee, and if you constantly are a NO when 90% of the committee is a YES and the candidate ends up being hired, then you'll end up building this reputation of being too tough or just not getting the right signals.
I've done 300+ interviews at Uber where the process is somewhat similar to Google, and OP's points are true. As an interviewer all you really want is get good signals either good or bad. And yes, an interview is much nicer when the candidate is doing great.
Do you (and the company) try to find new ways to interviews such that e.g. mid-career candidates don't need to practice in advance?
The current interview process at Google and probably at other companies as well seems to be frozen in time - one needs to be a fresh grad or prepare weeks/months in advance or be "into" competitive/sports programming, which in most cases has nothing to do with the daily job.
So no plans to have a fresh look on this?
Or maybe you keep these practices (and other companies follow) so that it is harder for engineers to change jobs easily?
I believe it is inappropriate to ask engineer to prepare in advance for the interviews.
Last time I got contacted by their recruiter and sent links to coding websites - I replied “Great for someone just out of college”.
Google, you are boring company with insane interview process. When I worked there 8 years ago I met many people, who thought passing the interview made them better than other. I regret I didn’t tell them that they should check their heads.
I got interviewed by Google twice, started by direct invitation from their HR team as I never applied to Google, naturally I bombed both times as I am not the PhD kind of developer they are after.
In every single time their recruiters were telling me our wonderful my CV was and they wanted definitely to have me there, naturally with a selection role totally unrelated for the kind of positions that I was applying for.
The third time I got a direct invitation from their HR team, I made it clear I wasn't interested if it was going to be again the same old way. Never got contacted again.
Recruiter's job is to get you there at any costs. I've being told before that cool team A,B and C wants to talk to me just to find that some boring team D is interviewing me.
> The system is _highly_ prejudiced towards suppressing false positives
I wonder if the algorithm centric interview style at Google can really achieve that. From my experience, algorithm centric questions + plus white board coding have bias towards academic people. (Maybe that’s fine for google) However, the way to crack that kind of interview is really just practice like hell on leetcode. Just take a minute and think, who are most motivated in doing that? Good, experienced engineers have no trouble finding jobs in Bay Area, and why would they waste their time on leetcode for skills that are mostly going to be useless in real work? New grads and engineers that have trouble finding jobs are most likely to spend hell of their time on leetcode. I think the interview style at Google is in fact increasing false positives instead of suppressing it. It also has high false negative for sure.
There are tons of other ways of doing interviews, in which interviewer gets a lot more and very relevant signals from candidates while keeping candidates pressure low, and not wasting their time, but Google is not doing it, like asking practical questions, letting candidates write and test their code in their own computers, has a debug session, etc.
I'm a UX Engineer at Google. The tasks we ask you to complete in an interview are very practical - sketching out the same kinds UIs that you might build in the real world.
The impractical part is that you'll probably be coding in a Google Doc rather than a text editor. It can be a bit disorienting.
I've also interviewed at Airbnb, where I was asked to code in Codepen for UI and in node for algorithms. I felt more comfortable in a more realistic coding environment, but one of their computers crashed mid-interview and the other's network access was broken. Coding in a doc and hand-waving when necessary is better than working in a more realistic environment if the hardware isn't reliable. (Realistic doesn't nec. mean unstable, but if you're expecting candidates to write working code in a fixed period of time, you need to make sure your communal interview machines are well-maintained.)
I was confused about interviews in big companies before. Especially sometimes you have interviewers from not the hiring team. I was also confused about how leetcode questions are used, and sometimes feel that justification on hiring or not hiring are not based on evidence. Then one day I changed my view. I am seeing interviews a way to evaluate candidates' wanting to a job, and his effort of trying to achieve something. If he can invest in time in leetcode, he definitely can learn and do well in any tasks. We are humans, and we can improve. So the interview does its job. Nothing is perfect of course.
The issue with Leetcode and HackerRank as I see it, is that you're reproving to various companies each time and each interview that you know how to code. However, the only alternative to this seems be an SAT for programmers, which isn't better.
To be honest, coding is not difficult. Also many jobs do not require 'that' much knowledge of low-level informations anyway. Especially nowadays, for most positions, you don't need to know re-ordering lines of code can affect the cache, you use hash whenever it is possible and do not need to implement your own data structure. If you do need something in your work and you currently don't know, google and reading will definitely teach you. Programming is not a special power only few people can have. Actually, if you are consistently learning, you will probably do well in any tasks. If people are not willing to put some time into getting the job they want, maybe they don't want the job enough.
>The system is _highly_ prejudiced towards suppressing false positives. This is the right decision,
This is textbook Google propaganda that has been repeated at least since I last worked there 5ish years ago. It's bullshit though because the ratio of competent to incompetent engineers was the same as at FB, MSFT and NFLX (with the latter tending to prune the fastest).
Just because you generate a system that spits out a lot of false negatives, it doesn't mean it has done anything to reduce false positives. This should be immediately obvious given that the relationship between the questions asked in G interviews and actual software engineering is non existent.
Don't repeat the trope that Google's hiring system is actually better at eliminating false positives. There is no evidence of it and if it truly was better, everyone would adopt it in a heartbeat and we wouldn't be working with bad engineers who spent a few months on leetcode to get into jobs way over their heads.
The reason Googlers never care to critically question the sorting hat is because it picked them.
All the FAANGs operate under a very similar hiring model, because they all get far more applicants than they can hire and can afford to have a high rate of false negatives. "Everybody" can't adopt it even if they wanted to, because your average business doesn't get a million applications a year.
That isn't really what the comment you're responding to was about. That comment was specifically about the fact that Google purports to target eliminating false positives and the trade off is accepting a high rate of false negatives. In fact there is not necessarily a relationship between the two: or at least not one that Google's process measures.
Oh, but they can and do. The difference between 100 and 1000 resumes is not material—both too many to look at. What I've found is those in the second bracket simply throw out those without a degree and then cargo-cult common practice.
"The reason Googlers never care to critically question the sorting hat is because it picked them."
I think this is a truism about the quality of most organizations - people who thrive in a specific organization coalesce into the organization and enhance those qualities within the organization that are specific to them.
I presume the fact that Google uses non-professional recruiters makes the recruitment process more about cultural alignment than it absolutely needs to be to gauge the capability to add value in a software engineering process.
> There is no evidence of it and if it truly was better
Year after year the Googlegeist survey finds that one of the things Googlers most enjoy about working at Google is their fellow employees
> if it truly was better, everyone would adopt it
Google has an abundance of money and an abundance of applicants who would like to work there. Companies with fewer applicants per position or lower salaries relative to the industry average may need to be more open to false positives if they want to be able to hire anyone at all. Smaller companies also have the advantage that they can usually fire people more easily than larger companies, which helps lower the cost of false positives for them.
>Year after year the Googlegeist survey finds that one of the things Googlers most enjoy about working at Google is their fellow employees
Hiring has very little to do with that. Perf review, feedback mechanisms, and work environment are orders of magnitude more critical to that. I've worked two startups with completely different hiring processes from Google and the other employees were amazing to work with there too. The key is feedback to correct issues and a quick PIP/fire process for folks not cutting it.
>This is textbook Google propaganda that has been repeated at least since I last worked there 5ish years ago. It's bullshit though because the ratio of competent to incompetent engineers was the same as at FB, MSFT and NFLX (with the latter tending to prune the fastest).
But those companies use hiring practices that approximate, to a high degree, what Google does. Facebook and Netflix certainly do, and Microsoft has a high enough rate of bad hires that you are required to reinterview to switch teams, so that high performing teams can keep reject bad candidates who are already at Microsoft.
I don't work for Google, so I don't know how much this applies to you folks. In my experience, while what you are describing is ideally correct, it's often just that -- an ideal.
For example, you'll have people insisting (and consciously agreeing) that their objective is to come out of the interview with enough evidence to give a positive or negative score. In the back of their minds, though, they will often be projecting their own insecurities -- about their expertise, about their career, about their job, about their team. Halfway through the interview, things end up being about something else altogether, like interviewers trying to reassure themselves that they're better than who they're interviewing (it's especially hard not to fall into this if it's been years since you last had to implement a red-black tree and you're interviewing a fresh graduate who dreams this stuff in their sleep).
It's very hard to get past these things. I struggle with them every time I interview someone, and it's very hard to know when to chalk it up to "the system" and when to chalk it up to your own baggage. Pretending that it's only the former only perpetuates this stuff -- and empowers the ones who actively enjoy abusing candidates and making them feel like crap just for the heck of it. Which is very common everywhere -- including, from what I've heard among my peers, at Google.
So far, the most relevant compass I've found for these things is made out of two questions:
1. If I were a candidate, and I'd have gone through this interview, how would I feel about it?
2. If I were to go through this exact interview today, would I still get hired?
If the answer to #1 isn't too good, there's probably some individual-level things you can change, but if the answer to #2 is bad, the problems tend to be more systemic in nature.
I agree that everyone has good intentions, but at the end of the day these interviews can be gamed really easily.
Before interviewing at Google I spent ~3 weeks doing leetcode style problems on a whiteboard I bought just for this purpose. Did not make me any better as a SWE, but definitely helped me clear my interviews. Without the practice I would have failed my interviews.
Having said that, I don't think I have any better alternatives; any interview process is ultimately going to be game-able in some manner.
Exactly. The bottom line is every interviewer is different and comes with their own quirks and biases. Writing another me too post just because you squeaked through the 5hr gambit isn't going to help anyone. I've met some interviewers (Google and elsewhere) who were incredibly arrogant, some who just wanted to see the solution and copy it down for proof etc. It's not black and white. Something has to change here.
The list contains good tips for avoiding getting nervous about something that's just normal practice, wasting time or running into a dead end. If you are concerned about the process, company culture or have any other concerns, use the time for questions at the end of the "main" interview. Interviewers will have better insights into the actual life of an engineer at G than recruiters. They don't have any incentive to misrepresent anything.
I like how the article tried to portrait these interviews as super professional and as if they have like a plan or something. My experience is that most interviewers dont prepare, they probably have been asking the same question for years. And no, they are not simultaneously interviewing for multiple skills, the just try to sound professional. If you are a dev, better leetcode. That's all that matters at Google.
I don't work at Google, but I've been doing technical interviews for years and I almost always ask the same question. The reason is I've given hundreds of interviews with that question, so I'm prepared for almost all the ways people can solve it, and especially all of the ways people get stuck or approach it in ways that would probably be useful if you had more than 45 minutes but aren't going to work in an interview setting.
When I've worked with interview plans it was around having the right mix of different technical interview styles and not really technical interviews (like often someone should run through the resume and validate things claimed)
i thought they said average score doesn’t correlate at all with how you do once you’re in? a lot of high performers only get in 2nd or 3rd time and barely.
I can't speak for whether that was true in the past.
(If you really care i can bug people for historical data)
However, as of 2014 average interview score was very well correlated with job performance (I can't give you further exact details because they are still marked confidential and i can't find a paper or anything that has disclosed it).
Note very clearly the word average above ;)
Individual interview scores are definitely not predictive of job performance.
Those interested in learning more would do well to read Kahneman's "thinking, fast and slow." Averaging across multiple axes and multiple interviewers gives good signal.
Yeah, I struggle with that, too. I've never interviewed with them, much less worked there, so everything I know or think I know about their interviewing process and work culture is second- or third-hand, but it sounds pretty miserable from the outside looking in. Still, they seem to attract a lot of people who really love working there, and they're producing things like Google maps, GMail, self-driving cars, Android, Google Docs, and a search engine... I'd be irritated if I interviewed there and was rejected (although I'm sure I have much worse interview rejection stories from far less prestigious employers), but I'm not sure that would necessarily mean that they're doing it wrong.
I keep reading about how bad Google's interview process is. But has anyone done any proper large scale research on what is the best way to hire software engineers? All the comments here seems like opinions of people based on themselves and no one provides a proper alternative. Just curious!
Yeah right - unless it's changed it was _only_ about solving the problem. Had an interview with them ~7 years ago, unfriendly, hard to understand interviewer asking about weighing boxes of pennies in minimum number of steps. I got it to 2, interviewer said "no, you can do it in 1" then refused to move forward. I had 10 years experience at that time and that was never discussed and also would not answer my questions about working at Google. Recruiter afterward ignored my follow up email.
I've interviewed three times in the last five or so years there, and I don't get the feeling the depth is as claimed in the article.
Perhaps, it's also the interviewers not implementing it as intended.
If these points were indeed important, I'd expect feedback addressing them. All feedback I received was about doing well or not well on certain questions. No meta whatsoever.
I didn't make it for good reasons, but I feel there is a big chance part.
I had one onsite interviewer in the first round who was difficult to deal with.
He presented a problem I've never seen in my life, nothing close. He interrupted and gave hints in directions that didn't make sense to me, and didn't give me 5 minutes to think without him talking.
The second attempt was fair.
In the third, the first phone screen's interviewer was constantly typing on his keyboard while I talked, and it was so loud. No real conversation happening. He was just staring in his screen clacking away. I addressed it, but he kept typing loudly while I was talking.
So annoying.
On the other hand, the recruiters were always very good.
At another company recruiting was a mess, and only knowing someone inside helped dealing with that, but the interviews were all great.
FYI, the reason one of your interviewers was typing is that they need to submit notes about the interview, and it's recommended to take notes ASAP (to avoid any bias post-interview).
No excuse for typing loudly + not stopping after you addressed it however. Sorry you've had a bad interview experience!
For what it's worth, I interviewed with Google twice, and got rejected the first time. One of my on-site interviewers asked me a simple question that has a large number of complex answers. I gave at least 4 different methods (all valid, with different pros/cons) to solve the problem, and they were not impressed at all...
the typing thing is a killer- they practically have to transcribe the entire thing so there is 0% chance of making any kind of human connection with your potential coworker.
Do people realize that there is no effective solution to this problem of hazing like interviews?
There are probably millions of High IQ people applying and vying to work at Google. Tomorrow Google could decide to add juggling competitions in interviews in addition to algorithm jargon and while it would lead to a lot more bitching from interviewers, it wouldn't matter to Google as they would still get their fill of qualified high IQ applicants.
You decided to latch on to one possible inaccuracy in what I said and disregard the overall point. Even if we agree that millions is not correct, 100s of thousands or thousands of people? Point is for every 1 qualified person hired at Google there are probably 100s of (at the very least) qualified people rejected. So Google can be unbelievably picky before any they see any bad effect from their hazing interviews on themselves.
I have recently interviewed at most of these companies, eventually managed to get some good offers at some of them, but let's be honest, I had to invest months in getting prep for the tech screening, whiteboard coding exercise and the whole non-sense jazz. I am sick of reading this blog posts because everyone knows, that is not how the majority of these interviews are conducted.
I have more than 10 years of experience on the field, I earned my degree in computer science years ago, but I had to go back and brush up on trie, tree, etc to convince the interviewers that I was worth working at company XYZ. The interview process is pretty much broken and very much biased towards fresh out of college eng. Unfortunately, if you really want to work at any of these companies you need to play their game and make them happy. Once you get the job, you will discover that most of your teammates are not as smart as they want you to believe they are and often you will be wondering how the hell did they manage to get a job at company XYZ. Well, they simply invested months prepping for the interview, plus they come from some well known university. Unfortunately when it comes to real work, they have no idea on how to get things done. What make things even worse is that often the tech screening is done by junior eng that have no idea and experience on how to conduct an interview and they expect the answers by the book.
A positive note: I also noticed that some companies are now giving take home exercise that are much closer to the day-to-day job. So maybe there is still hope.
As much as I agree that the process is bullshit, it is no different than studying for an exam, something we took for granted during school, just as a mean to an end (a degree), except that in this case there is arguably a much higher ratio of payoff/effort.
There is no mystery involved, one of the more known books on the subject is "Cracking the Coding Interview", but really there is no mystery to crack.
There is a ton of literature, tools, examples freely available on the Internet, all that is missing is time and effort to go through them and learn them as if it were for an exam.
One of the main objection is "Why I should spend more time in doing something I already do full-time at my job, where I'm perfectly qualified?", but to me it's pointless: if you think getting hired by another company will improve your life significantly (or even marginally), it is something you should definitely put effort into.
At the very least, this process (aside from those lucking out) proves that the candidate is able to understand a non-trivial problem (getting hired) and have the ability and put the effort necessary to solve it (going through the bullshit excercise and questions), as it was in your case.
Anyone who interviews at a "prestigious" company and then complains about how difficult the interview is kind of hypocritical. Google, and other FAANGs/unicorns, make you solve hard algorithms questions because they believe - correctly or wrongly - that in order to succeed as a company they have to filter out the vast majority of candidates who have poor algorithmic skills. They also pay a lot of money because that's the only way to attract enough candidates who can pass their hiring bar. If they stopped asking hard interview questions and increased their candidate acceptance rate they wouldn't need to pay people 300k/year to fill their open positions.
But the only reason people apply to Google and Facebook and Netflix in the first place is because they pay a lot of money. There are plenty of crappy CRUD shops that won't ask you to enumerate palindromic primes. As long as you can do Fizzbuzz they'll hire you and pay you 80k/year to glue libraries together. But people still try to interview at Google instead because they want to make 300k/year and not 80k/year. You can't have your cake and eat it.
To be fair the people who complain about this stuff probably don't think they pay this much either - I've seen a strong co-occurrence of salary denial in the same population!
I don't really agree with this position. I have friends at Big4, a lot in Facebook. I wouldn't say they are the type to know what palindromic primes are. When I interviewed there I didn't get any questions that required decent algorithmic skills.
I'm going to provide no justification; but just say that that sounds very "drink the cool-aid."
If you have such a high hiring bar — and you still get a sexist memo, or vocalised hate-crimes on your platform, or salary suppression, or workers being disallowed from using the bathrooms, or 20,000 employees staging a walk-out because of bonuses awarded to perpetrators of sexual assault... Maybe your a hiring bar is lower than it should be.
As far as I can tell, everything you just mentioned is totally orthogonal to coding/algorithms intelligence, so it’s not clear what point you’re making.
We’re not complaining that they’re difficult, we’re complaining that they’re stupid and a poor measure. This isn’t jealousy: I was hired by Google twice, but comparing my interviews and outcomes with friends and later coworkers, it seems like I just got luckier twice, and they dropped some way more talented people on the floor. The process is a total crapshoot, but like many things at the company nobody senior enough is willing to take ownership and fix it.
It's not really a crapshoot: It's a process with relatively few false positives and a fair number of false negatives. You and your "more-talented" friends are likely all above bar by some perspective on it, and the process let a subset of those through. It's imperfect (the number of false negatives is obviously higher than desirable), but that doesn't mean it's random.
I struggle to find evidence that this is any better anywhere else. At almost every other company I've worked at, the interview process was more about the referral itself (which leads to some pretty awful hires), or whether you can fake it til you make it.
Talent is not a single measure at Google. There are multiple facets to whether Google believes a candidate is solid. Strong technical talent is not an indicator of success, rather just one aspect of it that's taken into consideration by the hiring committees. So yeah, Google will say no to incredibly talented people because they fall short in other areas.
Crapshoot is table stakes practically everywhere you go. At least Google makes an attempt at making things objective and holistic.
FAANG companies don't pay anything near 300k USD annually in Europe, it doesn't happen. Probably 20% above the local market average. Their (certainly Google's) recruitment process in Europe is still the same demanding though. These are yet another companies in one's job application queue, and annoying ones.
Developer salaries are notoriously low in Europe and I’m not even camparing crazy SV or NYC salaries. I worked with devs in Europe working on the same platform and domain as me for half the salary. I haven’t heard of many low 6 figure developer jobs in and around the EU.
> They also pay a lot of money because that's the only way to attract enough candidates who can pass their hiring bar. If they stopped asking hard interview questions and increased their candidate acceptance rate they wouldn't need to pay people 300k/year to fill their open positions.
I have 16 years of total experience. Their initial offer to me indicated they thought I would take $231k/year for the privilege of working there. I got them up to $253k/year. Both numbers are less than I make now (though the latter is close).
As far as I am concerned, and based on my direct experience, Google pay is not the hit shit everyone claims it is. Maybe it would be if I played the competing offer game, but I shouldn't have to do that.
Maybe you just got a low offer and didn't perform to the standard they expected. Sometimes the companies give a lower offer because you didn't perform at the level they were expecting. (e.g. Performing at senior instead of staff)
Yeah, from what I've seen, Google seems to coast by on brand recognition more, and isn't usually as competetive in pay as Facebook or Netflix or the big decacorns unless you negotiate hard with lots of competing offers.
> filter out the vast majority of candidates who have poor algorithmic skills
No. Google, FB, interview this way because you don't have the skills on their stack, and this is the common denominator. (Source: I'm an engineer/manager at multiple FAANGs for the last decade.)
I sort of agree with you regarding the salary. The thing is, there are now a whole bunch of companies in the valley paying total comp close to or above 300k. You don't need to go to a FANG to get that. What you get at a FANG is name recognition and a chance to work on possibly more impactful or well known software. You also get the chance to deal with overachievers who think the only path to success is to work yourself to death for a FANG.
I cant believe this flavor of an answer has to be rewritten every single time FAANG salaries are discussed here. Reading the replies to this thread, lot of bitter people. I myself did not feel like relearning all my undergrad CS problems, so I simply never applied to FAANG engineering job, that simple.
They do it this way because they can, they have to weed out 99% of candidates, they are hiring for software engineers, it makes sens to weed out those who do not know perfectly core/advanced CS problems/solutions.
The problem is the rest of the industry looks to these companies for best practices and then proceed to cargo-cult them. If you think they can be avoided by applying to a greeting card or healthcare company instead, well I've got news for you.
> are plenty of crappy CRUD shops that won't ask you to enumerate palindromic primes.
Nope, every shop has convinced themselves they are changing the world, and do ask these questions, often on codepad.io. Even greeting card companies, hah.
I do contract work and interview often. Not one single place in the last two years hasn't tried these highly inefficient tactics on me.
I enjoyed my interview at Google. They asked some generic questions, but also some stuff specific to my niche.
No one is expecting perfect code. I ended up saying something along the lines of “let’s just pretend the method is called isPresent() because I forget” to every interviewer.
Hiring continues to be a favourite whipping boy on HN and honestly I kind of wish it would die because it's the same arguments every time:
- Inconsistent interviews
- Luck of the draw questions
- "I don't do well coding on a whiteboard" (often framed as "coding on a whiteboard proves nothing")
- Bad experience with the process
- Etc
Personally I don't mind coding on a whiteboard but only if you understand why you're asking a candidate to do it and what you hope to gain. Unfortunately many (IMHO) get this part wrong.
Obviously FizzBuzz was influential here. And I honestly think FizzBuzz is the right way to think about live coding tests because it's simple. It's deceptively simple such that anyone competent easily falls into the trap of thinking the question needs to be harder and this is a problem with many FAAMG interviewers.
On the other side I think there are people who don't realize how many people are masquerading as programmers who can't program a for loop in their language of choice. It's actually hard to believe for anyone semi-competent unless you've witnessed it but it's true.
FizzBuzz is a simple problem aimed at providing an early negative signal on a candidate. Every word of that was deliberate and important. It's simple so anyone remotely competent will pass it within minutes and you can move on.
This doesn't mean that if you ace it you're a good engineer ie there is ZERO positive signal here. The negative signal is if you can't solve this simple problem in your language of choice because then you almost certainly aren't a good engineer and you (the interviewer/employer) can stop wasting your time.
This is why it's so important it's a simple problem because a hard problem adds very little positive signal and greatly reduces the negative signal. Some people are bad under pressure with hard problems. Some questions are a matter of knowing the trick. Finding cycles in a graph is trivial if you are familiar with the tortoise and hare algorithm. If not you may figure it out from first principles but if you don't it doesn't mean you're a bad programmer or you shouldn't be hired. That's the problem.
On the other side some like to lambast interview processes if they have a nonzero false negative rate. These stories usually go "I referred excellent engineer X and they bombed out on a random coding question" or similar. This happens but getting a false negative doesn't invalidate the system.
It's important to remember to that the goals of the employer and the candidate are different. The candidate's goals are to try to get a positive signal to the employer. The employer's goals are to minimize time spent per candidate (since this is expensive) while hiring a sufficient number of qualified candidates with a minimum of false positives.
Again, every word of that is important. False positives are expensive. If you have a pool of 100 people to fill 10 roles and 20 are will work out then, as the employer, you don't often care which of those 20 you get, as long as you get 10 of them. There's an effort-reward curve between getting 10/20 qualified candidates vs the best 10.
Lastly, this is also why there is an interview slate of 4+ interviews. A single bad interview does not kill your chances.
I'd say Google's biggest problem is interviewer dead wood. These are people who have their pet questions, which were banned years ago (as either being too well known and/or just being a bad question) but they keep asking it anyway. Or they know <pick your language> and then force the candidate to use it and then mark them down for not knowing it (when the candidate never claimed to know it). Part of the delays in Google hiring too are some people will do an interview and won't submit feedback for 1 or even 2 weeks, a process I personally found inexcusable and infuriating.
The problem with FizzBuzz is that it's too well known. So it's basically something which has very little signal because people can just google it and memorize the solution.
Two of my favorite phone screen questions (now unfortunately banned because the have been identified on various web sites like Glassdoor as being Google interview questions) were "validate a UTF-8 string" (the interviewee is given the UTF-8 rules), and "add an integer to a bignum" (the interviewee is told what a bignum is if they don't know that term).
Both of these are really simple programming problems that the experienced coder should be able to knock off in 5 minutes. The absolutely terrifying thing is that there are fresh graduates with a CS degree who couldn't deal with either of these in the full 45 interview slot. I'm not sure what colleges are teaching these days, but it's certainly not programming as I know it...
The reason why these were my favorite phone screen questions was if the candidate couldn't hack a question like that, I could very confidently write up my interview report and tell the recruiter --- don't bother with the expense of bringing the candidate on site and asking 4-6 software engineers to spend 2-3 hours interviewing the candidate and then writing up a comprehensive set of interview notes/report.
The point is "like FizzBuzz" not "actually FizzBuzz". This could just as easily be:
- Add all the odd integers in an array
- Count the number of vowels in a String (bonus points if they ask about Unicode vs ASCII in the context of what constitutes a vowel). ASCII is the easy case. Unicode is a little more involved. Handle upper and lower case (they should figure out this is an issue).
- Given a set of Strings find all the characters (or words if you prefer) that are unique to only one of the Strings
- Given an ordered sequence 1..10 and the operators {+,-,/,*} where you can put any operator between two numbers but maintain the number order and operator precedence, find the number of operator combinations that yield 5 digit positive integers. Brute force is totally fine. Pick any category of answers you like in fact. Writing this one will take longer than FizzBuzz but the important point here is no specialist algorithmic knowledge other than how arithmetic works is needed and there is no special trick memorization.
I wouldn't even know where to start for the mostly trivial western European languages, and that's without leaving high bit ASCII territory.
I'd probably end up making a list by hand of every possible vowel. But that's not doable for Unicode. What does it even mean for things like ideographic characters?
> the experienced coder should be able to knock off in 5 minutes
An inexperienced one will knock off in 5 minutes.
An experienced one will know that the code you'll write in 5 minutes will be way too slow, by an order of magnitude slower than good library implementations.
I think these are great advices that would help to move a candidate from borderline hire/no hire to a hire, but let's be honest, you WON'T be hired if you don't solve the problems with a proper answer!
Months of preparation + LeetCode + Multiple interviews are critical to increase your chances to get an offer.
That was probably how her interviews went as a pretty lady. It’s quite possible. On the other hand, the normal guy probably had an adversarial interview process. So obvious! This is also true if the interviewee is buddy with a lot of the interviewers’ friends.
431 comments
[ 4.2 ms ] story [ 249 ms ] threadIf that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is?
I'd actually argue that for many companies this post is true (i.e. that getting it "right" is less important than the journey) but I still won't forgive companies that design the most hostile interview questions possible, and are then surprised when interviewees complain.
You can read the types of questions Google asks here:
https://www.glassdoor.com/Interview/Google-Software-Engineer...
I'd never interview at Google or any other company that operates this way. If the very first interaction I'm going to have is off-topic trivia, we're done, the company failed MY interview. The questions Google asks are disrespectful and unprofessional.
But disrespectful and unprofessional interview questions ("why are manhole covers round?") has become the new normal in this field.
Google's interview training is pretty specific about what is expected of an interviewer, and the interviewer has to write up fairly comprehensive reports about the questions that were asked, and how the candidate answers them, what hints were given, etc. Most interviewers ask questions that they have asked multiple times before, so they will include things like, "The candidate (TC) took twice as long to code this a very basic warmup question that was designed to motivate a more in-depth distributed computing question; unfortuantely, what a strong candidate could do in ten minutes, TC couldn't get working C code in 45 minutes". (Current best practice is to try to avoid revealing the gender of the candidate in the interview notes, hence the use of TC instead of he or she. The goal is to try to avoid triggering any unconscious bias on the part of the members of the hiring committee.)
Now, there are some screening questions that are asked by recruiters as part of an initial phone screen when they are hiring for SRE candidates. Those questions are multiple choice and are really basic questions designed to screen out old-school operators who are quite good at mounting tapes (for example) but don't have any understanding of what TCP might be, and who think an SRE job is no different from a traditional system administrator position. Those are not asked by an engineer, but by a recruiter; the goal is to avoid wasting everybody's time.
For a design question, the interviewer will write up a sketch of the design, what tradeoffs were identified by the interviewee; what hints, if any, were needed, etc.
Then the interviewer will rate candidate on various technical dimensions (coding efficiency, design, etc.) and non-technical dimensions (communication, leadership, etc.) For each of these ratings the interviewer has to justify the rating, by pointing at examples from the interview notes.
Finally, the interviewer will be asked to score the candidate along a dimension of "strong hire" to "strong no-hire" and again, the score must be justified with a paragraph. For people on the hiring committee, the justification for the scores are often far more important than the actual rating given by the interviewer.
The hire/no-hire decision is not up to the interviewers; the hiring committee is composed of a different panel of engineers who review the interview reports from the interview panel; and the members of the interview panel write their interview reports without getting to see or hear from the other members of the interview panel.
The system is not perfect (what system is?) but as someone who has conducted tens of interviews as a Googler and at other tech companies, I can say it's one of the most rigorous and fairest systems I've seen so far. Interviewers are trained to try and get candidates to a 'win', trained to be aware of their unconscious biases, and the hiring committee process reduces the significance of any one vote. In general, the process is designed to select the best candidates and give all candidates a positive experience.
It's not perfect -- indeed, I'm sure I've given 'failing-grade' interviews as an interviewer here and there -- but it's one of the least-worst human systems that I've encountered, from both sides of the process.
Besides being wrong and pathetic, why would anybody want to do that? The goal of maybe 90% of Google engineers is to spend as little time as the company allows on interviewing and writing feedbacks, and instead spend time on actually working on their projects.
Most interview systems don't have a systematic, ongoing way for accounting for this especially given that interviewers are self reporting.
In my opinion, most interviewers are undertrained/underskilled at asking specific questions and at interviewing in general. They don't invest the resources to systematically improve but rather treat interviewing as a burden to be minimized.
There is still a lot play in systems that allow for borderline smart ass behavior. Do you think an interviewer will write up that they sneered at the candidate?
The interview process is a factory. The company is mostly concerned with reaching outputs. The candidate is just a happenstance casualty.
Of course, that would be rediculously expensive, so at best some canned training is used instead. Still, it might make sense for higher value teams.
Afterwards, the new interviewer has to do a non-trivial number of interviews before they are considered "calibrated". When an interviewer is uncalibrated, their score won't be given much weight, and the hiring committee can see how their interview reports and scores compare against more experienced interviewers. This also gives an opportunity for the hiring committee to send interview feedback (e.g., you're asking a banned question; the coding question is too simple, so it's not providing enough of a useful signal; don't ask "trick questions" which again don't provide much useful signal whether or not the candidate can answer it correctly, etc.)
So there is certainly ways in which interviewers do get suggestions for improvement. And it doesn't have to be _that_ expensive. It's just a matter of making sure you don't have more than one uncalibrated interviewer per panel.
It won't be possible to extract any useful information from such interviews. But I guess it's possible to convince employees to haze candidates this way. You should feel bad for doing this to people though.
Empirically this isn't the case. It would be much more interesting if you took the time to elaborate on what about this process is cultish, why it won't provide useful signal. Without that, it just comes across as a mean-spirited complaint.
The sentence you're referring to was in the context of the FIELD which is why it said as much, and the specific question is a very well known stereotypical example:
> But disrespectful and unprofessional interview questions ("why are manhole covers round?") has become the new normal in this field.
If you browse my link you'll see that Google continues to ask off-topic questions, even if they aren't riddles or brainteasers.
Why don't they ask questions relating to the job? Why don't they do practice tasks that you'd be expected to do on the job? Those are the core issues.
When I hear of this sort of behaviour in interviews, I have to assume that the culture of the dept is such that x% of your job will entail fielding issues that are things that you consider outside your 'job'. If 20% of the time you'll be talking about stuff that you consider tangential, and you don't react well to that, you may self-select out. ?
The rest are paywalled or something. So I'd implore you to be more specific about what kinds of questions you object to.
"
I have read literally thousands of interviews at Google (both on hiring committees for 10+ years and in the group that reviews hiring committee decisions), and i just don't encounter them much. I can't even remember the last time i read this type of question.
I suspect your definition may be different than mine.
I do see that new grads/folks without a ton of experience get asked more questions to test fundamentals (not riddles), and folks otherwise get asked to just solve problems.
I have also seen occasional a few unscored warmup questions that are more abstract/riddlish for nervous people, but even that's pretty uncommon. It's usually small talk about resume instead.
Interviewers are also deliberately pushed to ask different questions if the candidate is not doing well (though it's slow to change interviewing behavior on this). Rather have signal on more questions than knowing that they really did badly on a single thing.
That means they may change style/abstractness of question depending on how interviewee is doing.
I've seen principal engineers (where this was the top of their ladder) that literally couldn't tell me what a hash table is.
For domain experts, Google actually does target domain specific areas (in at least 1 interview) and weigh it against how good people are generally.
However, I suspect most people think they are specialized experts in things they are not.
The really great jobs I’ve had didn’t really require interviews at all, they knew who I was and knew what I’ve done and what I could do, and that was good enough.
Since there is no incentive for a large number of engineers to cook up stories about their interview experience at Google, I am calling this smoke as having some fire behind it.
For my part, about every few months I hit something that would make a great interview question, and then have a wonderful afternoon coding it up... Ymmv.
I think there is incentive for failed interviewees to cook up stories - or at least to tell something very one-sided - because none of us like to believe we failed at something and feel better if we persuade ourselves it was stacked against us.
An incentive to maximize the value of their job position and already acquired leetcoding skills?
And in fact there's no need for explicit animosity by the failed interviewee. Someone who misunderstands a question badly enough to call it a brainteaser when it isn't is also likely to have performed badly on it.
This is an open internet forum for anyone to type anything they feel like in. Of course, as far as you know, I might be an Uzbeki 12-year old, so that argument only goes so far...
I can imagine that Google interviews for other roles than Software Engineers can have any kind of wacky questions. But mostly these stories sound so much like the stories that used to go around about Microsoft interviewing, only with the company name switched, that I have to think it has to do with their inherent virality somehow.
Yep. This is not the only instance were Google shows a culture of lack of respect for the dignity of the individual.
Because when you try to simulate those situations in an interview that needs to be conducted in 45 - 60 minutes, the questions become the kind you hate.
I regularly interview candidates; and some find my questions weird. The point is that I'm trying to simulate everything in such a short time. Otherwise, each interview would take 16-32 hours, because we'd have to go through a massive onboarding process just to ask basic questions.
I hate this meme so much. I personally have seen situations in my own work several times in the last few months where knowledge of algorithms, even on the leetcode medium level, was immensely helpful in finishing the job. If you can do it quicker and more fluently, you're probably going to be more productive.
I remember that there are test patterns built into T1 CSU/DSUs, but not what they are or how to turn them on -- if I need to know, I'll look it up.
I remember that there are three QoS bits in the IPv4 header, but not where they are. Probably pretty early, because of hardware implementations.
I remember that lots of people look down on Perl 5's object system, but not why. I remember the existence and purpose of lots of Perl modules, but not the interfaces.
I edit JSON and YAML every few weeks, but I don't have a conscious recollection of the rules -- they're prompted by looking at what's already there.
I can guesstimate Big-O notation on most chunks of code, but I'll be fooled when there's a function that's hidden in a library because I generally don't have those memorized.
I can tell you the bandwidth of lots of hardware interfaces, and the relative efficiency of speed and efficiency of storage for a handful of RAID configurations -- the ones that I set up, and the ones that I avoid.
I know one firewall configuration tool reasonably well, which means that I look up esoteric bits, and have used so many that I expect to do common things in all of them with a quick examination of the language.
I currently know a fair amount about GDPR and why it doesn't apply to my company (and how we can assist customers with their GDPR requirements) and lots about the Massachusetts and Virginia data privacy law. Very little about PCI compliance, but my point is: if my company wanted to do card transactions, I can figure out what I will need to learn to write a good policy and get it implemented in a way that won't embarass anyone.
In short: when the job is the same thing over and over again, you memorize the details. When it's always something new, you need a broad overview about what can be done and where to find the details.
The entire experience lasted less than an hour - from the time I walked into the reception till I walked out. Best job interview ever!
This codebase was probably 0.0000001% as complex compared to Google's (I can only imagine). Still, there is no reason more companies can't follow this style, at least for one of the several "rounds" of interviews, instead of whiteboard, trivia etc.
I'll take that module that auto-completes code with Stack Overflow answers first, thank you very much.
At the end of the day, this is what sucked the optimism out of me at my previous company. We had lots of people trying to steal from us. Even after I closed it down, I had two people in particular, ask me to help them design something, or give them detail domain/design knowledge, for free.
Yes, it happens. Far too often. Makes people like me jaded.
I had to tell one moron on phone interview that they are looking for free consulting or what because they keep harping a very specific project (Java/xml etc) setting that they were struggling with. It could of course be solved in hour or so by closely looking at product documents instead of endless googling.
When you are the guy who has to meet payroll for your team, and some (insert appropriate NSFW description here) person/company deprives you of pay for the work they are taking advantage of to further their goals ... think how that makes you feel.
There are many adjectives. None of them are synonymous with hilarious.
One uni called me up to tell me they liked my bid, but they wanted me to teach another company how to to what we could do, so they could buy from the other company.
The second uni issued an RFP, required that they get to keep all the docs, including detailed design specs. After interviewing all the companies, mine included, they selected 2 finalists, us and someone else. They probed us hard for details. Wound up buying our design from the other guys.
The prop shop did a similar thing, though we won the RFP. But then custy went silent while working on PO. They then awarded it to our competitor, as long as they used our design.
The semiconductor firm had a problem they claimed they could solve internally (they couldn't), and wanted to see what we could do. We met all of their (aggressive) performance, capacity objectives. But they kept pumping us for "free work" with the promise of a very large contract later. Against my business partner's recommendation, I called them on it, indicating that we'd be happy to work on the project with them. But not for free. So they "fired" us, as in asked us to stop working on it. Now, 4 years later, they are still struggling with the task.
Sadly, this is far too common.
> they wanted me to teach another company how to to what we could do
Here one might triple? their rate for a much shorter hourly design contract and leave implementation to someone else. The other two examples might have creative solutions as well.
I've seen this accusation thrown around dozens of times. I'm convinced that it's not really an actual issue, and just another way for bad candidates to transfer blame elsewhere.
This doesn't seem reasonable to me at all.
On the other hand, I can believe if this happens with those "take home assignments". Those tend to be larger (few hours to a few days) amount of work.
BTW, at least in this case, I did get the offer as they promised, within 48 hours. So I don't think they were doing anything shady. My guess is that they simply got tired of normal style interviewing and found this to be an efficient way to hire.
I had a two-hour session with senior tech leads solely about solving a specific severe scalability issue in one of their database systems that they had not made much progress on. I showed them how I'd solve it using a technique unfamiliar to them. Next day, I get a "when do you want to start?" call -- they tried my proposed solution in a test environment and it had worked as advertised.
Two hours solving one real-world design problem in my area of expertise. Simple and on point, without any trace of culture fit, leet code, random whiteboarding puzzles, etc.
As compared to say "are you going to have kids - to a woman "
That's not only disrespectful and unprofessional but potentially also illegal. But it isn't a contest to see who can be the most disrespectful or the most disrespected, so I don't follow your point.
Engineer. Diagnostics at Google Cloud. Keeping things boring. Personal opinions.
Emphasis mine.
However, I think if you ask people who conduct software engineer interviews at Google, a lot of them will agree with her opinion, including myself. One thing I would add, is that there is unfortunately no strong consensus on what to expect from the candidate, so variance seems to be high. That is why candidates are encouraged to try again, if unsuccessful.
That doesn't sound like a particularly useful answer.
[1] https://www.teamblind.com/article/google-engineer---total-co...
No one is going to be considered for both an L6 and L4 role.
L6 is a senior position, and not just in terms of title.
Your interviewers and and the type of questions asked depend on your potential level.
The expectations and responsibilities of an L4 and L6 differ so strongly that I'd be interested in a hypothetical candidate which could be both.
Slotting and MTS existed, but indeed hasn't been done since 2011 or 2012, and hadn't applied to L3 or L4 candidates for much longer, which means it likely was a way to differentiate between borderline L5 and L6 candidates or borderline L6 and L7.
Yes, it is. And this is a problem bigger than Google, this is simply one of the things that are going wrong on this planet. It is however one of the problems that are _relatively_ easier to fix.
A few observations:
- Modern society is so captured by social media, it's easy to make shallow connections but when it comes time to make the deeper connection, an actual hiring decision, hiring managers simply balk, and Loss Aversion Bias takes over.
- Being able to apply via the Internet creates too big a pipeline and shifts burden to the companies, which don't have the resources to handle the screening workload in a way that shows any consideration for the candidate.
- The shifting nature of technology makes the recruiting business hard. How is the average newcomer to recruiting supposed to be savvy enough to suss out the 12 different ways someone can be a "Docker Expert?" It's just absurd.
- Everyone hates the status quo. Job candidates, hiring managers, people who work in the staffing industry all hate the status quo and wish for a better way to guide talent toward the places where it is needed.
I don't see any way in which this is easy to fix.
Even if it's not standardized, a rubrik across X attributes with a scale and a number. (Which is what I am assuming they are doing anyway -- as it sounds likes the interviewers are rating them across different dimensions)
Not sure if this is some sort of a thing to do with liability but the interviewee can get generalized feedback.
Ex: Technical skills (2/5),Communication skills (4/5) etc. and they can improve on the relevant dimensions or compare notes with other companies / candidates as well.
More work for the company, and leads to even more negativity in the process.
https://news.ycombinator.com/item?id=6070001
The negativity may likely exist from no response/lack of feedback -- which can be frustrating for ppl that spent time/effort), but at least as the previous poster mentioned some people do appreciate feedback.
Also, recently noticed that companies have automated questionnaires asking how the recruiting process was or can be improved -- wondering if there's any improvements based on feedback.
As a side, it's been kinda interesting to read glassdoor responses for how people were treated/felt during the whole process (timing, professionalism etc...)
Yes, I can't remember where I came across the data, but providing feedback didn't actually increase interview satisfaction, but decreased it in the aggregate.
Candidates are prone to arguing and trying to nitpick the feedback to get reconsidered. It's counter intuitive, but that's what really happened.
Because all other companies just cargo cult what google does in interviews. If you want to switch jobs then this is interesting.
It's going away now but it kinda was not too long ago.
i just think its annoying because lots of companies cargo cult google and what thet do is a largely tangential skill set from the rigors of day to day programming work and knowledge. its a ritual from when they were hiring small numbers of graduate students with no real programming experience to measure them on. also the whiteboard is a relic of a time before there were laptops with hotswap 2nd screens.
You get 45 minutes, sometimes more if the interviewers can see that you’re close.
These days Google offers the option of a chromebook instead of a whiteboard.
thanks for explaining how coding interviews work to me thou, really had no idea based on the 200 i've administered in recent years or dozens taken in my career.
This definitely isn't advertised, I interviewed there on Friday for frontend and was presented with an entire wall to write on.
Would have preferred the Chromebook, could have done a final test run of the code, written out params and comments, tests, etc.
And then I read this >personal opinion
I'd rather take advice from /adv/
- Police officer: Just follow our instructions, be cooperative.
- Car salesman: Just be upfront with what you want. Tell us about yourself, and we'll earnestly try to help you.
The message is the same; the authority "just wants to help," but in reality the relationship is adversarial to a larger degree than it is cooperative. On Blind, you know the real way to getting through the Google interview is LeetCoding like hell and not admitting you've seen the questions before.
In cases where the interviewer is hiring for their own team, I feel like it's reasonable to assume that the interviewer is trying to hire people they want to work with. Acting in their own self interests, as it were.
In some cases that may mean "I want to make sure you are someone I'm able to collaborate with." In some cases that may be "LeetCoding like hell". Regardless, if that's what the interviewer is looking for, the candidate gets a really important insight in to the team they'd be working for and not necessarily indicative of some larger corporate conspiracy.
My attitude going in was that I was evaluating what it would be like to work there, and I treated the interviewer as a coworker solving a technical problem, where I was taking the lead.
The questions I got were pretty much exactly the sort of hing you see on LeetCode, but I hadn't seen any of the questions before. I know from studying for other technical exams that once you reach a certain number of practice problems, pattern recognition takes you a long way.
I had a similar experience at Facebook. Everybody was super nice, they all wanted you to do well, and they all responded well to being enthusiastic and genuinely interested in the problems you're solving.
I had the same experience. Afterwords I thought I did pretty well because I got to a solution to all the problems eventually.
Later when I discussed not getting the offer when a friend who works at Google. He said they try to guide the interviewee to a solution before the time limit. Which is reasonable, you want the interviewee to feel more confident and not get tilted by messing up just one question. However in hindsight the interview is a lot less enjoyable. You can't show any weakness solving a problem, less they offer you a "helpful hint" and record a black mark against you. The interviewer is there to smile and act like your colleague solving a problem while all the while making a list of why your a bad problem solver.
I'm not that bitter though. The interviewers that asked me questions actually related to the position I was interviewing (embedded software) did actually feel fun and collaborative. I accept that if I want to interview well at companies that employ these types of interview processes I will need to do every problem in CLRS (or at least more than zero).
But the impression I got as the interviewee was that every question ramped up in difficulty. The slope of the ramp-up depended on the question. So maybe in your case, you didn't get as far on the difficulty ladder as other people that were interviewed.
I was pretty shameless in asking for hints when I needed them, but it was typically of the form "I see this tradeoff here, and my gut says to do X, is that reasonable?" I'm sure some of that counted against me, but I was blunt about what I needed to make a decision and solve the problem, and I think overall that reflected well on my ability to problem solve on a team.
I would definitely not recommend doing every problem in CLRS. I would recommend doing just about every problem in Cracking the Code Interview (because they have nice answers), and then getting into a rhythm of doing LeetCode problems every day until the interview.
YMMV with interviewer, but personally, this is the type of thing that gets positive feedback from me - someone who understands and explains the tradeoffs involved.
Also, fair warning: LC has its uses, but it is not the same as an interview.
Yes, ramping up in difficulty is certainly a thing.
What gave me trouble, besides being rusty with algorithms, were some trade offs I would never make in the domain I'm familiar with. In my day job my microcontroller has 192KB of RAM, so limiting the amount of data collected to fit is important. I never get to the point where I have to worry about my simple algorithm not scaling to GB of data. Another odd idea was doing lots of speculative computation to reduce the latency of a system.
All of these algorithm things can be studied and after failing a couple of interviews you can start to understand what the interviewer is expecting and how to clarify assumptions.
I do question what sort of company you build if you screen for people who can write code on whiteboards. There is no giant mono-whiteboard where all the software engineers check in their code, so the interview process is not related to what people actually do for the job. On the other hand I have interviewed hundreds of people and I don’t feel like my questions do much better with the same one hour slot given to me by HR. The whole situation is inefficient for everyone.
This is really the crux of the problem. And the definition of 'hint' becomes real blurry at times.
But one interesting side effect of the interview process is that everybody at a place like Google or Facebook or Amazon has a non-trivial understanding of efficiency.
If nothing else, interviewing is an important part of your working life. To get a competitive job, you are probably going to have to practice something. I personally can get a lot more excited about competing on puzzle solving abilities than competing on social skills or social protocols, even if those puzzles might not be used very often once I'm at work.
(I'm not saying algorithms are completely unrelated to the work we do- I'm saying that even if they were, i'd still prefer to be tested on puzzles than to be tested on social skills)
I mean, the subtext here is that we're all getting interviewed for jobs we don't know how to do. All companies have their own infrastructure and their own way of doing things; you can't hire people with experience on that companies codebase unless you want to limit yourself to ex-employees. So all companies are interviewing to try to figure out who could learn how to do the job in question, and that's... pretty difficult to do.
The poster is correct that open ended questions that reveals the work ethic of team members are much more important than solving algorithms and hard problems. Intelligence is over rated.
On the other hand, there’s some signal (sorry) on the nature of the work you’re doing in whether SIGTERM (15) is imprinted in your brain from near-daily appearance on your screen, or not.
I would say a vital command-line skill is having a good filter to ignore what's irrelevant.
Signals 9 and 15 and much more well known by their respective value than their symbolic name. They are everywhere in program output and log files and if those things are your daily work then you recognize this whether you want to or not.
It's like if you have touched computer code in any language then you probably know that 65 is A. Not because you have useless trivial memorized but just because it figures every time you look at string values for some reason. In one sense it is useless trivia, but on the other hand a programmer who never stumbled on ascii codes must have lived in an unusually insular bubble.
I have never written a program that outputs a signal number to stderr or a log file. And grepping the logs on a server with nearly 800 days of uptime, I can find only five references to signal 15, from months ago.
> It's like if you have touched computer code in any language then you probably know that 65 is A. [..] a programmer who never stumbled on ascii codes must have lived in an unusually insular bubble.
20 years of programming and doing things like making custom fonts. I couldn't remember the ascii code of 'A'.
A bit more relevant would be what's the difference between this two
When I was at Google, I worked in a tiny office, and I was friends with the recruiter who worked that office. A couple of times she asked me to vet the answers to the non-technical questions, because if the candidate went off-script in any way, she simply couldn't tell if it's a wrong answer or a more in-depth answer than the script anticipated. This wasn't part of my job, and if our office wasn't so tiny we wouldn't have had any contact, and she wouldn't have had any engineers to ask.
So you're left with bad questions which have single answers, mostly involving rote memorization.
Additionally, it's common for interviewers to interview for multiple different groups (as an additional tech interviewer, a xfn interviewer, a Googleyness interviewer, etc), so exposure to job requirements can be reasonably broad at the interviewer level.
As I imagine many suspect, calibrating interviewers is hard, and always has been, for a company hiring roughly 10,000 people every year.
I have a friend who solved/memorized ~600 leetcode questions and got offers from Google, Facebook, etc. He was average, not dumb but not well above average. When I apply to both, I will definitely be leetcoding as many question as possible as well, to maximize my chances.
IME, my worst interview process ever was at Google. All I remember from it was some question about burning a piece of string. The coding part was relatively easy.
The best interview process I ever did was at Yahoo in 2008. Everyone was very friendly but the questions were tough. I found the “expert” level of the people interviewing me higher than at Google at the time. It was grueling though - 9am to 7pm. Got an offer to “join any team I wanted”. Turned it down for a startup.
Good decision in hindsight.
You have two identical ropes. If you light a rope on fire, it will finish burning in exactly one hour. The burn rate is inconsistent - there is no relationship between how much of the rope has burned, and how much time has passed, until the rope has fully burned away.
How can you use the two ropes to measure 15 minutes?
Given that it's printed in cracking the coding interview, Google has almost certainly banned this problem.
Well then, to go through and solve 600 leetcode questions actually takes a lot of dedication and time investment, which alone to me shows that your friend has a lot going for him. TBH, as someone who has hired a lot of engineers, if I found someone who was well rehearsed, and it was clear this person understood a lot of the underlying concepts in a problem as I dug deeper, I'd be thrilled to hire that person!
The fact is that Googles interview process isn’t designed to work for you or I, it’s desiged to work for them. The key factors that influence it are that they get tons of applicants, and they have a strong preference to eliminate false positives (which they can afford due to the previous point).
I’m not sure why somebody (seemingly earnestly) trying to help potential applicants understand the process should be the target of anti-authority criticism.
- A Google interviewer's (and I would assume any interviewer's) primary goal is to come out of the interview with enough confidence to give a positive or negative score. If they sit down to write feedback and have to give a neutral score, the interview wasn't productive. This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
- Doing interviews at Google is volunteer work. You are not interacting with a professional interviewer, you're interacting with someone whose day job is being an engineer. They don't have an evil agenda; they are doing this because they want to help Google hire the best candidates, and by inference make sure their future coworkers are good people to work with.
- Interviewers overwhelmingly _want_ their candidates to succeed. It's a true joy when I have a candidate who glides through a question (or finds a solution that was even better than mine). When candidates struggle, it's not a pleasant experience for the interviewer either.
- In the end, the point of technical interviews is to avoid the terrible experience that is working with an incompetent or uncooperative teammate. Interviewers are trying to find people that (a) can work well with others and (b) can get the work done.
- The system is _highly_ prejudiced towards suppressing false positives. This is the right decision, but it comes at the cost of a high rate of false negatives. Were myself or any of my colleagues to re-interview for our jobs, I would expect about a 60% hire rate. This is not even taking into account the constant ebb and flow of hiring demand. Sometimes there just isn't any headcount. And sometimes you just happen to get questions that you don't click with. This is also the reason that recruiters are so eager to bring you back to interview 6 months later.
- Recruiters and interviewers have very different incentives. Recruiters want to maximize the number of people they get hired; interviewers want to hire people they want to work with. This can lead to behavior that seems schizophrenic from the outside: the recruitment side of the pipeline constantly pestering people to interview, but once the candidate enters the interviewing pipeline the process is slow, deliberate, and careful.
Consider their financial incentives first before ascribing some altruistic motives.
This is only true if the interviewer is uninterested in what happens after the hiring process. If they want to make sure they're winning a reputation doing great interviews for more good hires than bad hires then there's an incentive to be cautious, and that caution could well manifest as trying to catch out anyone who might be 'gaming' the interview process. Those false positives reflect badly on the interviewer; the false negatives don't because they might have been real negatives.
Remember, interviewing is volunteer work, not something that will advance your career. The results of the interviews and committee deliberation are confidential, so there's no way to gain a reputation for being a "great interviewer".
One of the major flaws in Google's process is assuming that the engineers are incentivized to find good hires.
It's not a natural skill, dare I say it, especially for an engineer.
Sounds like a good interview question.
Source: I work & hire at Google. Opinions are my own.
I've done 300+ interviews at Uber where the process is somewhat similar to Google, and OP's points are true. As an interviewer all you really want is get good signals either good or bad. And yes, an interview is much nicer when the candidate is doing great.
The current interview process at Google and probably at other companies as well seems to be frozen in time - one needs to be a fresh grad or prepare weeks/months in advance or be "into" competitive/sports programming, which in most cases has nothing to do with the daily job.
So no plans to have a fresh look on this?
Or maybe you keep these practices (and other companies follow) so that it is harder for engineers to change jobs easily?
I believe it is inappropriate to ask engineer to prepare in advance for the interviews.
Last time I got contacted by their recruiter and sent links to coding websites - I replied “Great for someone just out of college”.
Google, you are boring company with insane interview process. When I worked there 8 years ago I met many people, who thought passing the interview made them better than other. I regret I didn’t tell them that they should check their heads.
In every single time their recruiters were telling me our wonderful my CV was and they wanted definitely to have me there, naturally with a selection role totally unrelated for the kind of positions that I was applying for.
The third time I got a direct invitation from their HR team, I made it clear I wasn't interested if it was going to be again the same old way. Never got contacted again.
Google stands on feet of clay
I wonder if the algorithm centric interview style at Google can really achieve that. From my experience, algorithm centric questions + plus white board coding have bias towards academic people. (Maybe that’s fine for google) However, the way to crack that kind of interview is really just practice like hell on leetcode. Just take a minute and think, who are most motivated in doing that? Good, experienced engineers have no trouble finding jobs in Bay Area, and why would they waste their time on leetcode for skills that are mostly going to be useless in real work? New grads and engineers that have trouble finding jobs are most likely to spend hell of their time on leetcode. I think the interview style at Google is in fact increasing false positives instead of suppressing it. It also has high false negative for sure.
There are tons of other ways of doing interviews, in which interviewer gets a lot more and very relevant signals from candidates while keeping candidates pressure low, and not wasting their time, but Google is not doing it, like asking practical questions, letting candidates write and test their code in their own computers, has a debug session, etc.
The impractical part is that you'll probably be coding in a Google Doc rather than a text editor. It can be a bit disorienting.
I've also interviewed at Airbnb, where I was asked to code in Codepen for UI and in node for algorithms. I felt more comfortable in a more realistic coding environment, but one of their computers crashed mid-interview and the other's network access was broken. Coding in a doc and hand-waving when necessary is better than working in a more realistic environment if the hardware isn't reliable. (Realistic doesn't nec. mean unstable, but if you're expecting candidates to write working code in a fixed period of time, you need to make sure your communal interview machines are well-maintained.)
This is textbook Google propaganda that has been repeated at least since I last worked there 5ish years ago. It's bullshit though because the ratio of competent to incompetent engineers was the same as at FB, MSFT and NFLX (with the latter tending to prune the fastest).
Just because you generate a system that spits out a lot of false negatives, it doesn't mean it has done anything to reduce false positives. This should be immediately obvious given that the relationship between the questions asked in G interviews and actual software engineering is non existent.
Don't repeat the trope that Google's hiring system is actually better at eliminating false positives. There is no evidence of it and if it truly was better, everyone would adopt it in a heartbeat and we wouldn't be working with bad engineers who spent a few months on leetcode to get into jobs way over their heads.
The reason Googlers never care to critically question the sorting hat is because it picked them.
Oh, but they can and do. The difference between 100 and 1000 resumes is not material—both too many to look at. What I've found is those in the second bracket simply throw out those without a degree and then cargo-cult common practice.
I think this is a truism about the quality of most organizations - people who thrive in a specific organization coalesce into the organization and enhance those qualities within the organization that are specific to them.
I presume the fact that Google uses non-professional recruiters makes the recruitment process more about cultural alignment than it absolutely needs to be to gauge the capability to add value in a software engineering process.
Year after year the Googlegeist survey finds that one of the things Googlers most enjoy about working at Google is their fellow employees
> if it truly was better, everyone would adopt it
Google has an abundance of money and an abundance of applicants who would like to work there. Companies with fewer applicants per position or lower salaries relative to the industry average may need to be more open to false positives if they want to be able to hire anyone at all. Smaller companies also have the advantage that they can usually fire people more easily than larger companies, which helps lower the cost of false positives for them.
Hiring has very little to do with that. Perf review, feedback mechanisms, and work environment are orders of magnitude more critical to that. I've worked two startups with completely different hiring processes from Google and the other employees were amazing to work with there too. The key is feedback to correct issues and a quick PIP/fire process for folks not cutting it.
But those companies use hiring practices that approximate, to a high degree, what Google does. Facebook and Netflix certainly do, and Microsoft has a high enough rate of bad hires that you are required to reinterview to switch teams, so that high performing teams can keep reject bad candidates who are already at Microsoft.
For example, you'll have people insisting (and consciously agreeing) that their objective is to come out of the interview with enough evidence to give a positive or negative score. In the back of their minds, though, they will often be projecting their own insecurities -- about their expertise, about their career, about their job, about their team. Halfway through the interview, things end up being about something else altogether, like interviewers trying to reassure themselves that they're better than who they're interviewing (it's especially hard not to fall into this if it's been years since you last had to implement a red-black tree and you're interviewing a fresh graduate who dreams this stuff in their sleep).
It's very hard to get past these things. I struggle with them every time I interview someone, and it's very hard to know when to chalk it up to "the system" and when to chalk it up to your own baggage. Pretending that it's only the former only perpetuates this stuff -- and empowers the ones who actively enjoy abusing candidates and making them feel like crap just for the heck of it. Which is very common everywhere -- including, from what I've heard among my peers, at Google.
So far, the most relevant compass I've found for these things is made out of two questions:
1. If I were a candidate, and I'd have gone through this interview, how would I feel about it? 2. If I were to go through this exact interview today, would I still get hired?
If the answer to #1 isn't too good, there's probably some individual-level things you can change, but if the answer to #2 is bad, the problems tend to be more systemic in nature.
At British telecom you had to pass a 3 day course before you where allowed to sit on internal review boards.
Mostly I just can't picture people from companies like Amazon or MS posting such stuff.
Before interviewing at Google I spent ~3 weeks doing leetcode style problems on a whiteboard I bought just for this purpose. Did not make me any better as a SWE, but definitely helped me clear my interviews. Without the practice I would have failed my interviews.
Having said that, I don't think I have any better alternatives; any interview process is ultimately going to be game-able in some manner.
When I've worked with interview plans it was around having the right mix of different technical interview styles and not really technical interviews (like often someone should run through the resume and validate things claimed)
The average interview score from a panel of interviews correlates very highly with performance at Google, interviewees report high satisfaction, etc.
If those things changed, i'm sure Google would change it. But why would they change it otherwise?
However, as of 2014 average interview score was very well correlated with job performance (I can't give you further exact details because they are still marked confidential and i can't find a paper or anything that has disclosed it).
Note very clearly the word average above ;) Individual interview scores are definitely not predictive of job performance.
Does it? looking at the pigsty that is the gmail redesign, it sure doesn't feel like they're hiring the brightest they could.
Yeah, I struggle with that, too. I've never interviewed with them, much less worked there, so everything I know or think I know about their interviewing process and work culture is second- or third-hand, but it sounds pretty miserable from the outside looking in. Still, they seem to attract a lot of people who really love working there, and they're producing things like Google maps, GMail, self-driving cars, Android, Google Docs, and a search engine... I'd be irritated if I interviewed there and was rejected (although I'm sure I have much worse interview rejection stories from far less prestigious employers), but I'm not sure that would necessarily mean that they're doing it wrong.
Think about it, if the probability of a random dev knowing your stupid questions is 1%, then you would need to interview 100 people to find that 1.
The only companies that can do that at scale are FAANG.
Much cheaper than the alternative which is to waste 2-4 hours per candidate.
Ostensibly this bad interview process is based on data.
So yeah, buzz off..
If these points were indeed important, I'd expect feedback addressing them. All feedback I received was about doing well or not well on certain questions. No meta whatsoever.
I didn't make it for good reasons, but I feel there is a big chance part. I had one onsite interviewer in the first round who was difficult to deal with. He presented a problem I've never seen in my life, nothing close. He interrupted and gave hints in directions that didn't make sense to me, and didn't give me 5 minutes to think without him talking. The second attempt was fair. In the third, the first phone screen's interviewer was constantly typing on his keyboard while I talked, and it was so loud. No real conversation happening. He was just staring in his screen clacking away. I addressed it, but he kept typing loudly while I was talking. So annoying.
On the other hand, the recruiters were always very good.
At another company recruiting was a mess, and only knowing someone inside helped dealing with that, but the interviews were all great.
No excuse for typing loudly + not stopping after you addressed it however. Sorry you've had a bad interview experience!
For what it's worth, I interviewed with Google twice, and got rejected the first time. One of my on-site interviewers asked me a simple question that has a large number of complex answers. I gave at least 4 different methods (all valid, with different pros/cons) to solve the problem, and they were not impressed at all...
There are probably millions of High IQ people applying and vying to work at Google. Tomorrow Google could decide to add juggling competitions in interviews in addition to algorithm jargon and while it would lead to a lot more bitching from interviewers, it wouldn't matter to Google as they would still get their fill of qualified high IQ applicants.
https://qz.com/285001/heres-why-you-only-have-a-0-2-chance-o...
Thanks for the heads up. ^^
There is no mystery involved, one of the more known books on the subject is "Cracking the Coding Interview", but really there is no mystery to crack.
There is a ton of literature, tools, examples freely available on the Internet, all that is missing is time and effort to go through them and learn them as if it were for an exam.
One of the main objection is "Why I should spend more time in doing something I already do full-time at my job, where I'm perfectly qualified?", but to me it's pointless: if you think getting hired by another company will improve your life significantly (or even marginally), it is something you should definitely put effort into.
At the very least, this process (aside from those lucking out) proves that the candidate is able to understand a non-trivial problem (getting hired) and have the ability and put the effort necessary to solve it (going through the bullshit excercise and questions), as it was in your case.
From subject matter taken from multiple 4 year degree fields. Science, engineering, theory, implementation, data XYZ, project management, sys admin…
Never happens at Uni, because it would be impossible. 99% of folks would fail, like they do in tech interviews.
But the only reason people apply to Google and Facebook and Netflix in the first place is because they pay a lot of money. There are plenty of crappy CRUD shops that won't ask you to enumerate palindromic primes. As long as you can do Fizzbuzz they'll hire you and pay you 80k/year to glue libraries together. But people still try to interview at Google instead because they want to make 300k/year and not 80k/year. You can't have your cake and eat it.
If you have such a high hiring bar — and you still get a sexist memo, or vocalised hate-crimes on your platform, or salary suppression, or workers being disallowed from using the bathrooms, or 20,000 employees staging a walk-out because of bonuses awarded to perpetrators of sexual assault... Maybe your a hiring bar is lower than it should be.
Talent is not a single measure at Google. There are multiple facets to whether Google believes a candidate is solid. Strong technical talent is not an indicator of success, rather just one aspect of it that's taken into consideration by the hiring committees. So yeah, Google will say no to incredibly talented people because they fall short in other areas.
Crapshoot is table stakes practically everywhere you go. At least Google makes an attempt at making things objective and holistic.
There's a lot of myopia in this thread.
I have 16 years of total experience. Their initial offer to me indicated they thought I would take $231k/year for the privilege of working there. I got them up to $253k/year. Both numbers are less than I make now (though the latter is close).
As far as I am concerned, and based on my direct experience, Google pay is not the hit shit everyone claims it is. Maybe it would be if I played the competing offer game, but I shouldn't have to do that.
Check out levels.fyi.
No. Google, FB, interview this way because you don't have the skills on their stack, and this is the common denominator. (Source: I'm an engineer/manager at multiple FAANGs for the last decade.)
They do it this way because they can, they have to weed out 99% of candidates, they are hiring for software engineers, it makes sens to weed out those who do not know perfectly core/advanced CS problems/solutions.
Nope, every shop has convinced themselves they are changing the world, and do ask these questions, often on codepad.io. Even greeting card companies, hah.
I do contract work and interview often. Not one single place in the last two years hasn't tried these highly inefficient tactics on me.
No one is expecting perfect code. I ended up saying something along the lines of “let’s just pretend the method is called isPresent() because I forget” to every interviewer.
- Inconsistent interviews
- Luck of the draw questions
- "I don't do well coding on a whiteboard" (often framed as "coding on a whiteboard proves nothing")
- Bad experience with the process
- Etc
Personally I don't mind coding on a whiteboard but only if you understand why you're asking a candidate to do it and what you hope to gain. Unfortunately many (IMHO) get this part wrong.
Obviously FizzBuzz was influential here. And I honestly think FizzBuzz is the right way to think about live coding tests because it's simple. It's deceptively simple such that anyone competent easily falls into the trap of thinking the question needs to be harder and this is a problem with many FAAMG interviewers.
On the other side I think there are people who don't realize how many people are masquerading as programmers who can't program a for loop in their language of choice. It's actually hard to believe for anyone semi-competent unless you've witnessed it but it's true.
FizzBuzz is a simple problem aimed at providing an early negative signal on a candidate. Every word of that was deliberate and important. It's simple so anyone remotely competent will pass it within minutes and you can move on.
This doesn't mean that if you ace it you're a good engineer ie there is ZERO positive signal here. The negative signal is if you can't solve this simple problem in your language of choice because then you almost certainly aren't a good engineer and you (the interviewer/employer) can stop wasting your time.
This is why it's so important it's a simple problem because a hard problem adds very little positive signal and greatly reduces the negative signal. Some people are bad under pressure with hard problems. Some questions are a matter of knowing the trick. Finding cycles in a graph is trivial if you are familiar with the tortoise and hare algorithm. If not you may figure it out from first principles but if you don't it doesn't mean you're a bad programmer or you shouldn't be hired. That's the problem.
On the other side some like to lambast interview processes if they have a nonzero false negative rate. These stories usually go "I referred excellent engineer X and they bombed out on a random coding question" or similar. This happens but getting a false negative doesn't invalidate the system.
It's important to remember to that the goals of the employer and the candidate are different. The candidate's goals are to try to get a positive signal to the employer. The employer's goals are to minimize time spent per candidate (since this is expensive) while hiring a sufficient number of qualified candidates with a minimum of false positives.
Again, every word of that is important. False positives are expensive. If you have a pool of 100 people to fill 10 roles and 20 are will work out then, as the employer, you don't often care which of those 20 you get, as long as you get 10 of them. There's an effort-reward curve between getting 10/20 qualified candidates vs the best 10.
Lastly, this is also why there is an interview slate of 4+ interviews. A single bad interview does not kill your chances.
I'd say Google's biggest problem is interviewer dead wood. These are people who have their pet questions, which were banned years ago (as either being too well known and/or just being a bad question) but they keep asking it anyway. Or they know <pick your language> and then force the candidate to use it and then mark them down for not knowing it (when the candidate never claimed to know it). Part of the delays in Google hiring too are some people will do an interview and won't submit feedback for 1 or even 2 weeks, a process I personally found inexcusable and infuriating.
But interviewing is on...
Two of my favorite phone screen questions (now unfortunately banned because the have been identified on various web sites like Glassdoor as being Google interview questions) were "validate a UTF-8 string" (the interviewee is given the UTF-8 rules), and "add an integer to a bignum" (the interviewee is told what a bignum is if they don't know that term).
Both of these are really simple programming problems that the experienced coder should be able to knock off in 5 minutes. The absolutely terrifying thing is that there are fresh graduates with a CS degree who couldn't deal with either of these in the full 45 interview slot. I'm not sure what colleges are teaching these days, but it's certainly not programming as I know it...
The reason why these were my favorite phone screen questions was if the candidate couldn't hack a question like that, I could very confidently write up my interview report and tell the recruiter --- don't bother with the expense of bringing the candidate on site and asking 4-6 software engineers to spend 2-3 hours interviewing the candidate and then writing up a comprehensive set of interview notes/report.
- Add all the odd integers in an array
- Count the number of vowels in a String (bonus points if they ask about Unicode vs ASCII in the context of what constitutes a vowel). ASCII is the easy case. Unicode is a little more involved. Handle upper and lower case (they should figure out this is an issue).
- Given a set of Strings find all the characters (or words if you prefer) that are unique to only one of the Strings
- Given an ordered sequence 1..10 and the operators {+,-,/,*} where you can put any operator between two numbers but maintain the number order and operator precedence, find the number of operator combinations that yield 5 digit positive integers. Brute force is totally fine. Pick any category of answers you like in fact. Writing this one will take longer than FizzBuzz but the important point here is no specialist algorithmic knowledge other than how arithmetic works is needed and there is no special trick memorization.
I can come up with a million examples like this.
Unicode is a little more involved?
I wouldn't even know where to start for the mostly trivial western European languages, and that's without leaving high bit ASCII territory.
I'd probably end up making a list by hand of every possible vowel. But that's not doable for Unicode. What does it even mean for things like ideographic characters?
An inexperienced one will knock off in 5 minutes.
An experienced one will know that the code you'll write in 5 minutes will be way too slow, by an order of magnitude slower than good library implementations.
For UTF8 see this: https://github.com/CppCon/CppCon2018/blob/master/Presentatio...
For bignums this: https://en.wikipedia.org/wiki/Intel_ADX
As you see, neither is solvable in 5 minutes.
The examples in a neighbor comment are very good, BTW.
Months of preparation + LeetCode + Multiple interviews are critical to increase your chances to get an offer.