8 ms·

All anecdotal evidence points to arriving at the correct, optimal solution as being key to passing the interview. It also seems like often times the interviewer

All anecdotal evidence points to arriving at the correct, optimal solution as being key to passing the interview. It also seems like often times the interviewers are not even going to be working with the candidate so their opinion on a 'working relationship' is mostly irrelevant. The objective of asking these leetcode style questions is to find candidates who are willing to put in the time to study. Success signals that this person is willing to commit to performing well at something that is reasonably challenging. The end result is that they are trying to hire worker bees. This makes sense as the bulk of work at any large company is largely mundane and relatively routine. I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense, although at that point the candidate is already well known in the industry most likely.

rvn1045 8y ago
Didnt the creator of home-brew not end up getting a job at google?
- minimaxir 8y ago
  That 2015 tweet (https://twitter.com/mxcl/status/608682016205344768?s=21 https://twitter.com/mxcl/status/608682016205344768?s=21) helped popularize the Google Interview memes, but things like Cracking the Code Interview still existed long before then.
  - brobdingnagians 8y ago
    One of the reply tweets linked an allegorical article about the pitfalls of whiteboard interviewing that I enjoyed quite a bit: http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-for-me-on.html http://www.unlimitednovelty.com/2011/12/can-you-solve-this-p...
    - bradleyjg 8y ago
      It’s totally fair to slag on whiteboard interviews, I hate them too. But it’s worth pointing out that there aren’t any great options out there. The traditional sit and have a chat interview is insanely biased towards people like the interviewer and doesn’t at all guarantee technical competence. The take home project feels like a big imposition to a lot of people, especially those that are currently employed, and raises concerns about cheating. The whiteboard interview except on a laptop has some advantages but has problems of comfort with the environment. I think a whiteboard or laptop interview with a cleaned up realistic problem, not a thinly disguised implement Dijkstra’s, is the least bad option around.
      - mixmastamyk 8y ago
        Strongly prefer the take-home project as long as it is confined to less than 4 hours. The gun-to-head aspect of the other choices significantly dominates other concerns in my experience.
    - gawkface 8y ago
      That creme brulee article was delicious, thanks for sharing!!
- deleted 8y ago
  [deleted]
- umanwizard 8y ago
  I always see this trotted out as proof of how bad Google’s interview process is, and I always wonder: what makes people think creating homebrew was particularly difficult or impressive? Package managers are a dime a dozen. It has also never been conclusively explained what “invert a binary tree” means (see the tweet a sibling comment linked to — that’s what the Homebrew guy claimed he wasn’t hired for not being able to do).
  - notyourday 8y ago
    There are more people in the world using homebrew than what most of Google engineers single handedly wrangled or produced -- excluding google products that came out of Google Labs that we now use. So if you want someone who can take shitty lemons and create a tasty lemonade out of it he is definitely your guy. Here's the thing - outside some special projects for which people are hired without going through the standard interview process Google does not want those who can take shitty lemons and convert them to tasty lemonade. Google wants specific kinds of butts that fit into a specific kind of seat. It wants the most homogeneous high output monkeys that would do what they are told, such as spitting out a code to invert a binary tree.
  - crdoconnor 8y ago
    Package management is a task filled with subtle pitfalls that is much, much harder than it looks on the surface. It's a lot like syncing files - e.g. how Dropbox looked similarly deceptively easy to build but really wasnt. IMHO the fact that the homebrew guy didn't get hired and that golang package management was a dumpster fire for years isn't coincidental. Both were part and parcel of a systemic bias that plagues Google's culture that they're blissfully unaware of.
    - philwelch 8y ago
      Google doesn’t do package management well because they don’t do package management at all; they have a monorepo. If anything, the systematic bias is that Google built their way around an entire class of problems that others still face.
- CydeWeys 8y ago
  I've seen people who otherwise did well at the coding parts of the interview not get an offer because they came off as a jerk, and no one wants to work with a jerk. There's way more to hiring decisions than raw engineering talent. Teamwork matters a lot too.
  - seattle_spring 8y ago
    Ironic, considering 3 of my interviewers during my last on-site with Google were complete jerks.
    - CydeWeys 8y ago
      That sucks. Remember, you're interviewing them as much as they're interviewing you. For what it's worth, all my Google interviewers were nice.
      - ummonk 8y ago
        Interesting. Two of the interviews in my onsite loop at Google felt test; one of them was incredibly disinterested and unhelpful - by far the worst interviewer I've ever had. I haven't bothered with Google this time around - combine the risk of jerk interviewers with the glacial pace of their interview process and it's not really something I'm interested in doing. And that's not even considering any personal reservations regarding the Damore firing or the massive payout to Rubin.
    - UncleMeat 8y ago
      Give that feedback to your recruiter. Committees can tell interviewers to get more training.
- romed 8y ago
  This guy’s response to not being offered a job validated the decision.
ma2rten 8y ago
Disclaimer: I haven't read the article, but I work at Google. Most interviewers will ask the same question to multiple candidates. They will compare how you the candidate is doing compared to other candidates on the same question. Most interviewers will provide hints. I'm pretty sure that all candidates go though the same interview process. There is really not much that is unique to Google's interviews. The only thing that is unique about the process is that your interview feedback is reviewed by a committee of peers.
- repsilat 8y ago
  > There is really not much that is unique to Google's interviews Having just gone through 10 days of on-site interviews (including two at Google), there are some things that are peculiar Google's process: - No talk about software engineering, - No talk about software design, - No talk about project management, working on a team, culture of any kind, caring about customers etc etc..., - No debugging, - No using unfamiliar APIs, no reading documentation, - No actually running any code. In particular, Google was the only place I didn't actually test and run my code. It was the only place where I was given the option of doing all of my work on the whiteboard, too. At least one time I had convinced my interviewer I had a working solution and then realised it didn't work and had to convince them of that...
  - vonmoltke 8y ago
    > It was the only place where I was given the option of doing all of my work on the whiteboard, too. I just interviewed at Facebook, and I was only given the option of doing all my work on a whiteboard. I hate that medium for writing code (or any dense text, really).
    - repsilat 8y ago
      Hmm. I programmed on my own laptop (and ran the code) at Instacart, Apple, Airbnb, Dropbox, Stripe, Cruise, Flexport and Benchling. Late September/October this year. At Google I wasn't allowed to bring my laptop, but they let me "program" in a text editor with syntax highlighting and automatic indentation. Most of the interviewers hadn't seen that before though.
bootsz 8y ago
My experience confirms this as well. I’ve interviewed at most FAANGs and many others, and made multiple attempts at some. Brute-force practice (e.g. leetcode problems) and memorization is the only thing that ultimately worked. It would be nice if interviews really were a “collaborative” experience to see “how you think” where finding the optimal answer “doesn’t matter”. But it 100% does.
- Bartweiss 8y ago
  Years ago, I had the rare experience of being told why I didn't get an offer from a big Valley tech company. (Not FAANG, but perceived similarly.) It was for an internship, and I suspect they wanted to keep candidates interested for full time applications. The relevant interview was a "find the palindrome" question for which the desired answer was Rabin-Karp. The rejection was explicitly "your solution to the whiteboard algorithm question worked but wasn't optimal, so study your algorithms harder and try again in the future". At the time, I thought it was pretty stupid that they tried to judge skill by requiring candidates to either have one random thing memorized or reinvent a publication-worthy algorithm in 30 minutes. But given the advice I got, it seems like the core motivation was "we want people who are willing to devote a bunch of free time solely to impressing us". And for that, asking impractical questions and demanding optimal answers works perfectly.
lallysingh 8y ago
Actually you just have to say "Hashtable" three times and they have to give you a job.
- expertentipp 8y ago
  Actually the spell is „hashtable hashtable stack pop pop push”.
drewg123 8y ago
It is true that you will almost never work with somebody who interviewed you. In some ways, this is absolutely terribly for hiring. I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially". So we'd pre-screen people with the knowledge we needed, and then pass them off to others to officially interview. They would almost invariably fail, because their non domain-specific knowledge was not in the top 1% or whatever it takes to pass a generic interview. So we were left with the choice between hiring contractors, or training somebody internal who could leave at any time. We hired contractors. EDIT: See the sibling comment regarding the homebrew author. This situation was exactly like that. Imagine wanting to hire somebody to make an internal package manager, and not being allowed to hire the author of one of the most popular package managers because his whiteboarding skills were lackluster, so he got a poor interview score from people that have no idea (or concern) what he does or what he's being hired to do.
- superzadeh 8y ago
  I work in a startup, with a team of 8, and you will 100% work with those that interview you :)
- andybak 8y ago
  > I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially". When a company policy is so obviously broken in this way and there is no way to route around it then something is very broken. Here's how it should work. You explain the issue above to someone above you and they either have the authority to get round it or they pass it on to someone who does. If a policy is failing in such a profound way and nobody can change it this implies a level of organisational dysfunction that must be affecting multiple aspects of the company.
  - drewg123 8y ago
    One way to route around it is to acquire a company with the needed expertise. However, it needs to be a large-ish company. There is some cutoff beyond which engineers from acquired companies do not need to re-interview for their jobs. It is somewhere between 10 person startup and Motorola, but I have no idea where. I don't think a way to route around it for an individual position or candidate exists.
walrus1066 8y ago
'I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense' Can testify to this, interviewed via referral, was still asked some algo-trivia, didn't do too well on that but still got a decent offer, mainly because referee vouched for me based on their experience working with me.
- strangerlands 8y ago
  Either (a) they want you or (b) they want someone like you. If (a), they find any reason for hiring you, if (b) they find any reason for not hiring you. This explains most of the interview dynamics, especially at large companies.
myth_buster 8y ago
> I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense As a commenter mentioned in a different thread, two sigmas get acqui-hired. I remember reading about FB acquisition of Instagram/WhatsApp, there was a requirement that they had some understanding of cs concepts.
UncleMeat 8y ago
Anecdotal evidence from an interviewer. Maybe 5% of candidates hit the optimal solution for my problem. It is absolutely 100% not necessary in order to do well in my interviews.
fizwhiz 8y ago
As someone who conducts interviews frequently on behalf of Google, I'm in a position to categorically reject your claim that someone with {PRESTIGIOUS_COMPANY_X || INDUSTRY_REPUTATION} is given an easier path. Please note that I haven't interviewed anyone with 30+ years of experience (yet) and I only interview candidates for SWE roles (not Research Scientist roles) so view my experience from that lens since because I still think it's applicable to a majority of the crowd here on HN. Everyone (regardless of background) has to sing for their supper, so to speak. Sure, having good pedigree can make it easier to get scheduled for an interview, but that in no way means you're slated to have interviews with people who will handle you with kid-gloves. On the contrary, the whole process is designed to zap out any bias and cover a large amount of breadth. Interviewers have questions they're calibrated themselves on, and if they get picked for the loop they just usually ask those questions. This is true from the phone screen all the way through the on-site. You may feel that established engineers cross-pollinating from other competitive companies don't have to jump through as many hoops but that's only because they've been through this rodeo enough to know how to prepare for it well. Many are hobbyist competitive programmers and people who build stuff on the side so the interview questions don't blindside them completely.
- rademacher 8y ago
  I wasn't implying that the interview was easier for candidates with recognizable track records. Perhaps two sigma was not restrictive enough. I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk. Do you really want to remove bias for experienced candidates with a track record of substantial and nontrivial contributions?
  - fizwhiz 8y ago
    > I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk. To put in bluntly, if you are such a candidate you are expected to know your algorithms cold and be expected to field your domain specific questions. So if you're a well-known compiler designer you would still need to know how to wield algorithms/datastructures for parts of the interview loop and then get into detail about compilers in the domain-specific parts of the loop. That being said, it totally depends on the position you're interviewing for. If you're interviewing for Director/VP role in an engineering ladder, then some of the interview will need to be repurposed to getting signals about leadership and impact. That doesn't mean that you don't code at all though, it just means that the focus/weightage will be moved towards other dimensions (in addition to evaluating your system design and coding skills).

rvn1045 8y ago

Didnt the creator of home-brew not end up getting a job at google?

minimaxir 8y ago
That 2015 tweet (https://twitter.com/mxcl/status/608682016205344768?s=21 https://twitter.com/mxcl/status/608682016205344768?s=21) helped popularize the Google Interview memes, but things like Cracking the Code Interview still existed long before then.
- brobdingnagians 8y ago
  One of the reply tweets linked an allegorical article about the pitfalls of whiteboard interviewing that I enjoyed quite a bit: http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-for-me-on.html http://www.unlimitednovelty.com/2011/12/can-you-solve-this-p...
  - bradleyjg 8y ago
    It’s totally fair to slag on whiteboard interviews, I hate them too. But it’s worth pointing out that there aren’t any great options out there. The traditional sit and have a chat interview is insanely biased towards people like the interviewer and doesn’t at all guarantee technical competence. The take home project feels like a big imposition to a lot of people, especially those that are currently employed, and raises concerns about cheating. The whiteboard interview except on a laptop has some advantages but has problems of comfort with the environment. I think a whiteboard or laptop interview with a cleaned up realistic problem, not a thinly disguised implement Dijkstra’s, is the least bad option around.
    - mixmastamyk 8y ago
      Strongly prefer the take-home project as long as it is confined to less than 4 hours. The gun-to-head aspect of the other choices significantly dominates other concerns in my experience.
  - gawkface 8y ago
    That creme brulee article was delicious, thanks for sharing!!
deleted 8y ago
[deleted]
umanwizard 8y ago
I always see this trotted out as proof of how bad Google’s interview process is, and I always wonder: what makes people think creating homebrew was particularly difficult or impressive? Package managers are a dime a dozen. It has also never been conclusively explained what “invert a binary tree” means (see the tweet a sibling comment linked to — that’s what the Homebrew guy claimed he wasn’t hired for not being able to do).
- notyourday 8y ago
  There are more people in the world using homebrew than what most of Google engineers single handedly wrangled or produced -- excluding google products that came out of Google Labs that we now use. So if you want someone who can take shitty lemons and create a tasty lemonade out of it he is definitely your guy. Here's the thing - outside some special projects for which people are hired without going through the standard interview process Google does not want those who can take shitty lemons and convert them to tasty lemonade. Google wants specific kinds of butts that fit into a specific kind of seat. It wants the most homogeneous high output monkeys that would do what they are told, such as spitting out a code to invert a binary tree.
- crdoconnor 8y ago
  Package management is a task filled with subtle pitfalls that is much, much harder than it looks on the surface. It's a lot like syncing files - e.g. how Dropbox looked similarly deceptively easy to build but really wasnt. IMHO the fact that the homebrew guy didn't get hired and that golang package management was a dumpster fire for years isn't coincidental. Both were part and parcel of a systemic bias that plagues Google's culture that they're blissfully unaware of.
  - philwelch 8y ago
    Google doesn’t do package management well because they don’t do package management at all; they have a monorepo. If anything, the systematic bias is that Google built their way around an entire class of problems that others still face.
CydeWeys 8y ago
I've seen people who otherwise did well at the coding parts of the interview not get an offer because they came off as a jerk, and no one wants to work with a jerk. There's way more to hiring decisions than raw engineering talent. Teamwork matters a lot too.
- seattle_spring 8y ago
  Ironic, considering 3 of my interviewers during my last on-site with Google were complete jerks.
  - CydeWeys 8y ago
    That sucks. Remember, you're interviewing them as much as they're interviewing you. For what it's worth, all my Google interviewers were nice.
    - ummonk 8y ago
      Interesting. Two of the interviews in my onsite loop at Google felt test; one of them was incredibly disinterested and unhelpful - by far the worst interviewer I've ever had. I haven't bothered with Google this time around - combine the risk of jerk interviewers with the glacial pace of their interview process and it's not really something I'm interested in doing. And that's not even considering any personal reservations regarding the Damore firing or the massive payout to Rubin.
  - UncleMeat 8y ago
    Give that feedback to your recruiter. Committees can tell interviewers to get more training.
romed 8y ago
This guy’s response to not being offered a job validated the decision.

ma2rten 8y ago

Disclaimer: I haven't read the article, but I work at Google. Most interviewers will ask the same question to multiple candidates. They will compare how you the candidate is doing compared to other candidates on the same question. Most interviewers will provide hints. I'm pretty sure that all candidates go though the same interview process. There is really not much that is unique to Google's interviews. The only thing that is unique about the process is that your interview feedback is reviewed by a committee of peers.

repsilat 8y ago
> There is really not much that is unique to Google's interviews Having just gone through 10 days of on-site interviews (including two at Google), there are some things that are peculiar Google's process: - No talk about software engineering, - No talk about software design, - No talk about project management, working on a team, culture of any kind, caring about customers etc etc..., - No debugging, - No using unfamiliar APIs, no reading documentation, - No actually running any code. In particular, Google was the only place I didn't actually test and run my code. It was the only place where I was given the option of doing all of my work on the whiteboard, too. At least one time I had convinced my interviewer I had a working solution and then realised it didn't work and had to convince them of that...
- vonmoltke 8y ago
  > It was the only place where I was given the option of doing all of my work on the whiteboard, too. I just interviewed at Facebook, and I was only given the option of doing all my work on a whiteboard. I hate that medium for writing code (or any dense text, really).
  - repsilat 8y ago
    Hmm. I programmed on my own laptop (and ran the code) at Instacart, Apple, Airbnb, Dropbox, Stripe, Cruise, Flexport and Benchling. Late September/October this year. At Google I wasn't allowed to bring my laptop, but they let me "program" in a text editor with syntax highlighting and automatic indentation. Most of the interviewers hadn't seen that before though.

bootsz 8y ago

My experience confirms this as well. I’ve interviewed at most FAANGs and many others, and made multiple attempts at some. Brute-force practice (e.g. leetcode problems) and memorization is the only thing that ultimately worked. It would be nice if interviews really were a “collaborative” experience to see “how you think” where finding the optimal answer “doesn’t matter”. But it 100% does.

Bartweiss 8y ago
Years ago, I had the rare experience of being told why I didn't get an offer from a big Valley tech company. (Not FAANG, but perceived similarly.) It was for an internship, and I suspect they wanted to keep candidates interested for full time applications. The relevant interview was a "find the palindrome" question for which the desired answer was Rabin-Karp. The rejection was explicitly "your solution to the whiteboard algorithm question worked but wasn't optimal, so study your algorithms harder and try again in the future". At the time, I thought it was pretty stupid that they tried to judge skill by requiring candidates to either have one random thing memorized or reinvent a publication-worthy algorithm in 30 minutes. But given the advice I got, it seems like the core motivation was "we want people who are willing to devote a bunch of free time solely to impressing us". And for that, asking impractical questions and demanding optimal answers works perfectly.

lallysingh 8y ago

Actually you just have to say "Hashtable" three times and they have to give you a job.

expertentipp 8y ago
Actually the spell is „hashtable hashtable stack pop pop push”.

drewg123 8y ago

It is true that you will almost never work with somebody who interviewed you. In some ways, this is absolutely terribly for hiring. I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially". So we'd pre-screen people with the knowledge we needed, and then pass them off to others to officially interview. They would almost invariably fail, because their non domain-specific knowledge was not in the top 1% or whatever it takes to pass a generic interview. So we were left with the choice between hiring contractors, or training somebody internal who could leave at any time. We hired contractors. EDIT: See the sibling comment regarding the homebrew author. This situation was exactly like that. Imagine wanting to hire somebody to make an internal package manager, and not being allowed to hire the author of one of the most popular package managers because his whiteboarding skills were lackluster, so he got a poor interview score from people that have no idea (or concern) what he does or what he's being hired to do.

superzadeh 8y ago
I work in a startup, with a team of 8, and you will 100% work with those that interview you :)
andybak 8y ago
> I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially". When a company policy is so obviously broken in this way and there is no way to route around it then something is very broken. Here's how it should work. You explain the issue above to someone above you and they either have the authority to get round it or they pass it on to someone who does. If a policy is failing in such a profound way and nobody can change it this implies a level of organisational dysfunction that must be affecting multiple aspects of the company.
- drewg123 8y ago
  One way to route around it is to acquire a company with the needed expertise. However, it needs to be a large-ish company. There is some cutoff beyond which engineers from acquired companies do not need to re-interview for their jobs. It is somewhere between 10 person startup and Motorola, but I have no idea where. I don't think a way to route around it for an individual position or candidate exists.

walrus1066 8y ago

'I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense' Can testify to this, interviewed via referral, was still asked some algo-trivia, didn't do too well on that but still got a decent offer, mainly because referee vouched for me based on their experience working with me.

strangerlands 8y ago
Either (a) they want you or (b) they want someone like you. If (a), they find any reason for hiring you, if (b) they find any reason for not hiring you. This explains most of the interview dynamics, especially at large companies.

myth_buster 8y ago

> I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense As a commenter mentioned in a different thread, two sigmas get acqui-hired. I remember reading about FB acquisition of Instagram/WhatsApp, there was a requirement that they had some understanding of cs concepts.

UncleMeat 8y ago

Anecdotal evidence from an interviewer. Maybe 5% of candidates hit the optimal solution for my problem. It is absolutely 100% not necessary in order to do well in my interviews.

fizwhiz 8y ago

As someone who conducts interviews frequently on behalf of Google, I'm in a position to categorically reject your claim that someone with {PRESTIGIOUS_COMPANY_X || INDUSTRY_REPUTATION} is given an easier path. Please note that I haven't interviewed anyone with 30+ years of experience (yet) and I only interview candidates for SWE roles (not Research Scientist roles) so view my experience from that lens since because I still think it's applicable to a majority of the crowd here on HN. Everyone (regardless of background) has to sing for their supper, so to speak. Sure, having good pedigree can make it easier to get scheduled for an interview, but that in no way means you're slated to have interviews with people who will handle you with kid-gloves. On the contrary, the whole process is designed to zap out any bias and cover a large amount of breadth. Interviewers have questions they're calibrated themselves on, and if they get picked for the loop they just usually ask those questions. This is true from the phone screen all the way through the on-site. You may feel that established engineers cross-pollinating from other competitive companies don't have to jump through as many hoops but that's only because they've been through this rodeo enough to know how to prepare for it well. Many are hobbyist competitive programmers and people who build stuff on the side so the interview questions don't blindside them completely.

rademacher 8y ago
I wasn't implying that the interview was easier for candidates with recognizable track records. Perhaps two sigma was not restrictive enough. I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk. Do you really want to remove bias for experienced candidates with a track record of substantial and nontrivial contributions?
- fizwhiz 8y ago
  > I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk. To put in bluntly, if you are such a candidate you are expected to know your algorithms cold and be expected to field your domain specific questions. So if you're a well-known compiler designer you would still need to know how to wield algorithms/datastructures for parts of the interview loop and then get into detail about compilers in the domain-specific parts of the loop. That being said, it totally depends on the position you're interviewing for. If you're interviewing for Director/VP role in an engineering ladder, then some of the interview will need to be repurposed to getting signals about leadership and impact. That doesn't mean that you don't code at all though, it just means that the focus/weightage will be moved towards other dimensions (in addition to evaluating your system design and coding skills).