10 ms·

Google is overrated. It's been obvious for over a decade after they built an interview process that is heavily biased towards those who recently took an algorit

by ken47 3y ago

Google is overrated. It's been obvious for over a decade after they built an interview process that is heavily biased towards those who recently took an algorithms class. You had talking heads yammering about how hard it was to get into Google, which to be honest, made the company even less appealing. Is this a software engineering company or some kind of hyped up nightclub? Yeah, maybe it's a hard interview if you've been out of college for a while, haven't written classical algorithms professionally for years, and don't want to spend weeks or months of free time bashing your head on leetcode. What isn't pressure tested by the Google interview process? Just about every other skill that is needed to be a good software engineer. Obviously, Google has some good engineers, but my goodness was the hype around the company offputting.

ChatGTP 3y ago
I think there is some truth to this for sure, it doesn't mean you're hiring practical / driven people, it means you're likely hiring people who are good at rote memorization.
- smugglerFlynn 3y ago
  It means you are hiring people who are highly compliant. Which is important when your goal is to scale whatever already works.
hiq 3y ago
> It's been obvious for over a decade after they built an interview process that is heavily biased towards those who recently took an algorithms class. What would you do instead? Threads about tech interviews are always the same: we all complain about the process with no real alternative when you want to hire at that scale. In particular about: > Just about every other skill that is needed to be a good software engineer. How would you assess them better than current common processes like leetcode interviews? If one could do better hiring at the same cost or less, the whole industry would be interested, even if they'd have to delegate some of their hiring to an external company. The fact that leetcode interviews are still so common indicates that maybe something is missing from alternatives, be it scalability, fairness or even whether they actually provide more signal than leetcode interviews.
- ken47 3y ago
  I've seen plenty of HN threads where good alternative processes were described. I'm not going to be exhaustive here: writing a program over a few hours that is reflective of the kind of work that the company actually does, coming up with and debating the architecture of a system, mock code reviews, etc. You might say these don't scale as well as standardized testing of university classical algorithms knowledge. The general response to that would be that if you're optimizing for scale, then you're not optimizing for quality, so stop the hype around Google only hiring "the best." It's telling that as Google has begun to regularly lay off engineers, they have also begun to deemphasize classical algorithms in their interview process.
  - deleted 3y ago
    [deleted]
  - okdood64 3y ago
    > they have also begun to deemphasize classical algorithms in their interview process Can you elaborate?
  - hn_throwaway_99 3y ago
    To your point, while I haven't interviewed with Google, don't they actually do a number of the things you're talking about (e.g. ask about system design or ask you to look at some existing code)? I'm guessing every interviewer isn't asking you some variation of "find a loop in a linked list".
  - trympet 3y ago
    At big tech companies, "writing a program over a few hours that is reflective of the kind of work that the company actually does" is not really a good, representative performance measure. Often times, you will be solving problems across multiple domains, outside of your area of expertise. You have to take on the role of PM, data scientist, SWE, researcher, etc. Internal restructuring of the company may even take you from working on backend web apis to distributed databases. It is expected that you re-acclimatize and learn quickly. Giving you a take-home test to write some CRUD app isn't necessarily sampling those same attributes. p.s.: also not a fan of classical algorithm style interviews. Clearly, they also have a bias.
devjab 3y ago
I don’t think Google is necessarily overrated instead I think they have some issues being both an advertising company and something else. I look at them from an EU enterprise perspective. Back 10-15 when the big move into the cloud started Google was ahead of their competition. They had online office, and they still have some excellent services that are sort of unmatched by both Amazon and AWS in terms of managed backends like Firebase, but today they make up almost no enterprise sales. This is largely because they never managed to transition into a world where they could sell their products to enterprise. One part is their data and privacy policies which are an obvious issue the other part is support. One of the most important things Microsoft sells to Enterprise is support, and I don’t mean the stuff you and I get as private persons, I mean how their headquarters will call your CTO with updates when something goes down, how you have direct channels to get things changed like when teams was turned on by default instead of something your IT department controlled, or how you can even visit their Azure server centres and look at “your” server if you’re a big enough customer. This is why AWS sort of “lost” in the EU, because when they first entered the market they had the automated support similar to what Google has now, where you can talk to a useless chatbot and never get anywhere even if you’re paying them millions of dollars. Unlike Google, Amazon quickly adjusted and suddenly they had better support and EU compliance than Microsoft (who still can’t guarantee that only EU citizens ever work on the maintenance of their data centres where your data is stored). The one place Google was a little different was in Education. They actually seemed to know how to sell that, but even here their advertising roots are now losing them deals. Because now there is a focus on how everything in Google education is shared with Google, and while that data might be valuable to Google it’s losing them all their sales in education, which also means they lose the data… Unless Google somehow changes course, and becomes both an advertising company, and, a tech company, they are just never going to be relevant outside of advertising again. At least for Enterprise, but even as a private customer, you’re probably thinking twice about their products considering how many of them they shut down. I think it’s a shame considering a lot of their products are very good and affordable, but is what it is.
password54321 3y ago
Most "leetcode" questions they ask are just easy level programming puzzles. The fact that many developers seem to hate it and even struggle with it says more about the developers applying than it does about Google.
- mcntsh 3y ago
  The fact that there are whole industries built on training these puzzles is a big signal that you're wrong. Also it's funny that engineers leaving Google, Amazon, et all NEED to practice these skills in order to get other roles because it just shows that these skills aren't needed (read: exercised, grown) working in their day-to-day jobs.
  - password54321 3y ago
    >The fact that there are whole industries built on training these puzzles is a big signal that you're wrong. Wrong about what? That they are easy? If you know binary search, sorting, sets, hash tables, recursion then it is easy. If you wanted to make it more aligned with what a developer does day to day the alternative is doing a small project in your own time which is more time consuming for everyone.
    - HarHarVeryFunny 3y ago
      Leetcode "easy" questions are just common sense application of everyday algorithms and data structures. These might make sense for an automated screening test of "is this candidate lying about knowing the language". But, then there's the ones that are all about specific techniques such as dynamic programming + memoization, or specific graph algorithms etc, etc. Any decent programmer can learn how to do these harder problems under time pressure (interview) through practice, but this is really about Leetcode grinding prep... these are not problems you would likely encounter in most jobs, and in the real world you'd just Google for algorithms or ask a colleague if you needed help.
  - CoastalCoder 3y ago
    > The fact that there are whole industries built on training these puzzles is a big signal that you're wrong. I'm not sure that logic alone is a compelling: It's conceivable that this secondary industry addresses a real gap in university curricula, or a need for ongoing training of experienced developers. But I think your overall point still holds, because there's a consensus that a large number of Leetcode-like puzzles require familiarity with problems and solutions that hardly every come up in real professional software development, and aren't even good proxies for the abilities that do matter.
kyrra 3y ago
I joined Google 11 years into my career. So while I had taken an algorithms class recently, I just reread the algorithm book I used in college and spent a bunch of time studying all of them. I actually found it a lot of fun, as it was a good refresher for myself.
- bmikaili 3y ago
  It‘s not as easy as it was 11 years ago. There‘s a whole industry behind it and an arms race between preparation and more difficult problems.
  - smsx 3y ago
    They didn't say they joined 11 years ago, but that they were 11 years into their career.
- cmrdporcupine 3y ago
  The problem is it only works for a certain personality and thinking type that can do that under pressure in front of an interviewer. Most of us who have been in the industry for a while solve algorithm problems by working in an editor or REPL, and do so in a solitary way, with time to pause and think. The Google-style process (that so many people copied) acts as if the ability to do that kind of thinking under time pressure and in front of a generally-elitist interviewer is some kind of marker of the ability to work on the job. It isn't. Plus I worked at Google for a decade and the amount of times I had to do actual algorithm/data structure fundamental stuff was about 0. 90% of Googlers are wiring existing crap together, and if they stray outside of that they'll get spanked in a code review anyways.
HarHarVeryFunny 3y ago
I wouldn't characterize Leetcode interviewing as being biased towards those who recently took an algorithms class - it's biasing in favor of those (of any level of experience) who are willing to spend a few months practicing Leetcode. I thought that Google/etc had at least dialed this back a bit, or maybe just dialed back the "how many gas stations are in the US" type questions, after realizing this wasn't the best predictor of good performance.
- helen___keller 3y ago
  > or maybe just dialed back the "how many gas stations are in the US" type questions, after realizing this wasn't the best predictor of good performance. These problems (known as fermi problems) have been out of vogue for over a decade now. Google is one of the companies that pioneered algorithm-centric leetcode problems as a replacement for fermi problems. Leetcode problems are not hugely useful outside of the data given by solving a fizzbuzz. Rather, it’s just another excuse so interviewers can convince themself a person is smart, call it signal, and justify a hire. The last time Google gave me a job offer, one of my interviews was literally a souped up fizzbuzz - straightforward imperative code with no trick, no complicated algorithms, and no fancy data structures. I suppose that may be the reason I got an offer, that I didn’t need fancy algorithms that I hadn’t prepared. Ultimately it’s impossible to know if someone will be a good hire from an interview. Being a good engineer requires a bunch of traits that simply can’t be tested. The leetcode interview, as I see it, acknowledges this weakness and instead chooses to filter out low-effort candidates, as anyone persistent can practice leetcoding and interviewing (in theory).
  - Rebelgecko 3y ago
    This is pretty consistent with my experience. I had one hardcore algorithms question that I bombed, but the other ones hinged on things like "when should you use a map vs a list" that should be second nature to anyone who has been writing code long enough.
  - datagram 3y ago
    > a bunch of traits that simply can’t be tested I think there's a lot more that could be tested that what current implementation-centric interviews measure. At my company for example, I feel like we've gotten a lot of use out of our debugging interviews.
cmrdporcupine 3y ago
Having worked there I agree on some points. I thought the interview process was bullshit. But, people generally work there for two reasons: Pay and benefits top-knotch. I made two times there what I'm making now, post-Google, and I'm still making more 30% than my peers who work in-office for local companies do. (I work remote). Free food and other perks were also amazing. Exposure to really large systems and scale. A lot of people really get off on building systems that scale as big as some of the Google stuff. And honestly the internal engineering quality at Google is excellent. But conservative, and bespoke. They build their own everything, which they can do because they have buckets of cash. And what they build is mostly superior, and more consistently engineered. The internal code quality is generally meticulous.
lokar 3y ago
I did over 400 interviews working there, and many hundreds more serving on hiring committees. I never gave a leetcode interview, and saw only a modest amount of them in committee. “It’s all leetcode BS” makes a great offhand d complaint but was not the actual truth.
- deleted 3y ago
  [deleted]
- mportela 3y ago
  Then I'm super unlucky because my last phone interview there 3 weeks ago was definitely Leetcode.
  - bradlys 3y ago
    I’ve interviewed there multiple times over the years. It was full of typical leetcode shit. There’s a reason there’s a list of problems on leetcode tagged as Google having used them recently…
- Apocryphon 3y ago
  Okay, then what questions did you give in interview?
  - lokar 3y ago
    I personally did a lot of system design, debugging (systems or code), or deep technical dive (explain in more and more detail how something works and why it works that way).
- 01100011 3y ago
  I only interviewed once with them, but there wasn't anything I'd consider leetcode. There was a rather aggressive interviewer who drilled me on an architectural web services question despite interviewing for a systems programming position on Fuchsia and having a resume solely in embedded/systems programming. From my limited experience I'd say the interview process is broken, but not in the way people on here think.
pompino 3y ago
Ironically, many of their software products are bloated and slow as fuck. (There are some that are top class too, but just sayin.. )
- trogdor 3y ago
  >many of their software products are bloated and slow as fuck Which? I regularly use Gmail, Maps, Drive, Docs, Sheets, Home, Voice, and Takeout. I don’t think any of those are bloated or slow, but maybe I’m missing something. I’m also curious which you think are top class.
  - pompino 3y ago
    The ones I think are top class are not really end-user oriented, it's core stuff like the search engine, their JS engine, etc. (IMO) The bloated ones are their webapps that suck up gigabytes and gigabytes of ram and CPU resources (client side) for basic stuff like showing you one couple of pages of emails or playing a video file.
summerlight 3y ago
Unless you're willing to spend more than 20~30% of your engineer's precious time on the hiring process (or have GPT-7 or whatever GAI lol), it will always be BS. And that's not scalable; this could work when your hiring is mostly through employee's personal/professional network since ROI will be better than average, but when you need to hire thousands new employees it will quickly become a bottleneck. The only thing you can do is designing an acceptable level proxy done with high efficiency. Unfortunately we don't really have a good way there to figure out something more efficient than coding interview + system design interview yet. A good interviewer can still extract a surprising amount of valuable signals within 45 mins but not everyone is interested in being a good interviewer.
heads 3y ago
As I’ve grown more senior in age and rank I’ve come to realise just how important it is to carry on the selection process after the interview, during probation, and managing performance throughout your hire’s entire journey. It just feels so incredibly imprecise relying on a few hours of meetings to gauge if someone is good or not, and the probationary period is crucial for correcting mistakes. Frankly, we also can’t afford to say no accidentally to someone who would turn out to be a great hire. I’m seeing this now through the lens of hiring at a 100 person org, but I’ve done hundreds of interviews as a FAANG employee too. The difference there, I would say, and what GOOG try to do is to shoot for the moon and get hiring nailed at the interview process. This comes at the expense of rejecting nine out of ten candidates because the candidate firehouse is free flowing and plentiful: something I don’t have at my much more normal startup.
- ken47 3y ago
  I’ve don’t think I’ve ever seen engineers complain about the rejection rate of Google’s interview process. The more common criticism/meme regards the laziness of running candidates through a unidimensional leetcode gauntlet. Half joking, but why even have engineers run these interviews at all? A proctor could get the same job done at a fraction of the cost. If a proctor can run the interview process, then how valuable is the signal?

by ken47 3y ago

ChatGTP 3y ago

I think there is some truth to this for sure, it doesn't mean you're hiring practical / driven people, it means you're likely hiring people who are good at rote memorization.

smugglerFlynn 3y ago
It means you are hiring people who are highly compliant. Which is important when your goal is to scale whatever already works.

hiq 3y ago

> It's been obvious for over a decade after they built an interview process that is heavily biased towards those who recently took an algorithms class. What would you do instead? Threads about tech interviews are always the same: we all complain about the process with no real alternative when you want to hire at that scale. In particular about: > Just about every other skill that is needed to be a good software engineer. How would you assess them better than current common processes like leetcode interviews? If one could do better hiring at the same cost or less, the whole industry would be interested, even if they'd have to delegate some of their hiring to an external company. The fact that leetcode interviews are still so common indicates that maybe something is missing from alternatives, be it scalability, fairness or even whether they actually provide more signal than leetcode interviews.

ken47 3y ago
I've seen plenty of HN threads where good alternative processes were described. I'm not going to be exhaustive here: writing a program over a few hours that is reflective of the kind of work that the company actually does, coming up with and debating the architecture of a system, mock code reviews, etc. You might say these don't scale as well as standardized testing of university classical algorithms knowledge. The general response to that would be that if you're optimizing for scale, then you're not optimizing for quality, so stop the hype around Google only hiring "the best." It's telling that as Google has begun to regularly lay off engineers, they have also begun to deemphasize classical algorithms in their interview process.
- deleted 3y ago
  [deleted]
- okdood64 3y ago
  > they have also begun to deemphasize classical algorithms in their interview process Can you elaborate?
- hn_throwaway_99 3y ago
  To your point, while I haven't interviewed with Google, don't they actually do a number of the things you're talking about (e.g. ask about system design or ask you to look at some existing code)? I'm guessing every interviewer isn't asking you some variation of "find a loop in a linked list".
- trympet 3y ago
  At big tech companies, "writing a program over a few hours that is reflective of the kind of work that the company actually does" is not really a good, representative performance measure. Often times, you will be solving problems across multiple domains, outside of your area of expertise. You have to take on the role of PM, data scientist, SWE, researcher, etc. Internal restructuring of the company may even take you from working on backend web apis to distributed databases. It is expected that you re-acclimatize and learn quickly. Giving you a take-home test to write some CRUD app isn't necessarily sampling those same attributes. p.s.: also not a fan of classical algorithm style interviews. Clearly, they also have a bias.

devjab 3y ago

I don’t think Google is necessarily overrated instead I think they have some issues being both an advertising company and something else. I look at them from an EU enterprise perspective. Back 10-15 when the big move into the cloud started Google was ahead of their competition. They had online office, and they still have some excellent services that are sort of unmatched by both Amazon and AWS in terms of managed backends like Firebase, but today they make up almost no enterprise sales. This is largely because they never managed to transition into a world where they could sell their products to enterprise. One part is their data and privacy policies which are an obvious issue the other part is support. One of the most important things Microsoft sells to Enterprise is support, and I don’t mean the stuff you and I get as private persons, I mean how their headquarters will call your CTO with updates when something goes down, how you have direct channels to get things changed like when teams was turned on by default instead of something your IT department controlled, or how you can even visit their Azure server centres and look at “your” server if you’re a big enough customer. This is why AWS sort of “lost” in the EU, because when they first entered the market they had the automated support similar to what Google has now, where you can talk to a useless chatbot and never get anywhere even if you’re paying them millions of dollars. Unlike Google, Amazon quickly adjusted and suddenly they had better support and EU compliance than Microsoft (who still can’t guarantee that only EU citizens ever work on the maintenance of their data centres where your data is stored). The one place Google was a little different was in Education. They actually seemed to know how to sell that, but even here their advertising roots are now losing them deals. Because now there is a focus on how everything in Google education is shared with Google, and while that data might be valuable to Google it’s losing them all their sales in education, which also means they lose the data… Unless Google somehow changes course, and becomes both an advertising company, and, a tech company, they are just never going to be relevant outside of advertising again. At least for Enterprise, but even as a private customer, you’re probably thinking twice about their products considering how many of them they shut down. I think it’s a shame considering a lot of their products are very good and affordable, but is what it is.

password54321 3y ago

Most "leetcode" questions they ask are just easy level programming puzzles. The fact that many developers seem to hate it and even struggle with it says more about the developers applying than it does about Google.

mcntsh 3y ago
The fact that there are whole industries built on training these puzzles is a big signal that you're wrong. Also it's funny that engineers leaving Google, Amazon, et all NEED to practice these skills in order to get other roles because it just shows that these skills aren't needed (read: exercised, grown) working in their day-to-day jobs.
- password54321 3y ago
  >The fact that there are whole industries built on training these puzzles is a big signal that you're wrong. Wrong about what? That they are easy? If you know binary search, sorting, sets, hash tables, recursion then it is easy. If you wanted to make it more aligned with what a developer does day to day the alternative is doing a small project in your own time which is more time consuming for everyone.
  - HarHarVeryFunny 3y ago
    Leetcode "easy" questions are just common sense application of everyday algorithms and data structures. These might make sense for an automated screening test of "is this candidate lying about knowing the language". But, then there's the ones that are all about specific techniques such as dynamic programming + memoization, or specific graph algorithms etc, etc. Any decent programmer can learn how to do these harder problems under time pressure (interview) through practice, but this is really about Leetcode grinding prep... these are not problems you would likely encounter in most jobs, and in the real world you'd just Google for algorithms or ask a colleague if you needed help.
- CoastalCoder 3y ago
  > The fact that there are whole industries built on training these puzzles is a big signal that you're wrong. I'm not sure that logic alone is a compelling: It's conceivable that this secondary industry addresses a real gap in university curricula, or a need for ongoing training of experienced developers. But I think your overall point still holds, because there's a consensus that a large number of Leetcode-like puzzles require familiarity with problems and solutions that hardly every come up in real professional software development, and aren't even good proxies for the abilities that do matter.

kyrra 3y ago

I joined Google 11 years into my career. So while I had taken an algorithms class recently, I just reread the algorithm book I used in college and spent a bunch of time studying all of them. I actually found it a lot of fun, as it was a good refresher for myself.

bmikaili 3y ago
It‘s not as easy as it was 11 years ago. There‘s a whole industry behind it and an arms race between preparation and more difficult problems.
- smsx 3y ago
  They didn't say they joined 11 years ago, but that they were 11 years into their career.
cmrdporcupine 3y ago
The problem is it only works for a certain personality and thinking type that can do that under pressure in front of an interviewer. Most of us who have been in the industry for a while solve algorithm problems by working in an editor or REPL, and do so in a solitary way, with time to pause and think. The Google-style process (that so many people copied) acts as if the ability to do that kind of thinking under time pressure and in front of a generally-elitist interviewer is some kind of marker of the ability to work on the job. It isn't. Plus I worked at Google for a decade and the amount of times I had to do actual algorithm/data structure fundamental stuff was about 0. 90% of Googlers are wiring existing crap together, and if they stray outside of that they'll get spanked in a code review anyways.

HarHarVeryFunny 3y ago

I wouldn't characterize Leetcode interviewing as being biased towards those who recently took an algorithms class - it's biasing in favor of those (of any level of experience) who are willing to spend a few months practicing Leetcode. I thought that Google/etc had at least dialed this back a bit, or maybe just dialed back the "how many gas stations are in the US" type questions, after realizing this wasn't the best predictor of good performance.

helen___keller 3y ago
> or maybe just dialed back the "how many gas stations are in the US" type questions, after realizing this wasn't the best predictor of good performance. These problems (known as fermi problems) have been out of vogue for over a decade now. Google is one of the companies that pioneered algorithm-centric leetcode problems as a replacement for fermi problems. Leetcode problems are not hugely useful outside of the data given by solving a fizzbuzz. Rather, it’s just another excuse so interviewers can convince themself a person is smart, call it signal, and justify a hire. The last time Google gave me a job offer, one of my interviews was literally a souped up fizzbuzz - straightforward imperative code with no trick, no complicated algorithms, and no fancy data structures. I suppose that may be the reason I got an offer, that I didn’t need fancy algorithms that I hadn’t prepared. Ultimately it’s impossible to know if someone will be a good hire from an interview. Being a good engineer requires a bunch of traits that simply can’t be tested. The leetcode interview, as I see it, acknowledges this weakness and instead chooses to filter out low-effort candidates, as anyone persistent can practice leetcoding and interviewing (in theory).
- Rebelgecko 3y ago
  This is pretty consistent with my experience. I had one hardcore algorithms question that I bombed, but the other ones hinged on things like "when should you use a map vs a list" that should be second nature to anyone who has been writing code long enough.
- datagram 3y ago
  > a bunch of traits that simply can’t be tested I think there's a lot more that could be tested that what current implementation-centric interviews measure. At my company for example, I feel like we've gotten a lot of use out of our debugging interviews.

cmrdporcupine 3y ago

Having worked there I agree on some points. I thought the interview process was bullshit. But, people generally work there for two reasons: Pay and benefits top-knotch. I made two times there what I'm making now, post-Google, and I'm still making more 30% than my peers who work in-office for local companies do. (I work remote). Free food and other perks were also amazing. Exposure to really large systems and scale. A lot of people really get off on building systems that scale as big as some of the Google stuff. And honestly the internal engineering quality at Google is excellent. But conservative, and bespoke. They build their own everything, which they can do because they have buckets of cash. And what they build is mostly superior, and more consistently engineered. The internal code quality is generally meticulous.

lokar 3y ago

I did over 400 interviews working there, and many hundreds more serving on hiring committees. I never gave a leetcode interview, and saw only a modest amount of them in committee. “It’s all leetcode BS” makes a great offhand d complaint but was not the actual truth.

deleted 3y ago
[deleted]
mportela 3y ago
Then I'm super unlucky because my last phone interview there 3 weeks ago was definitely Leetcode.
- bradlys 3y ago
  I’ve interviewed there multiple times over the years. It was full of typical leetcode shit. There’s a reason there’s a list of problems on leetcode tagged as Google having used them recently…
Apocryphon 3y ago
Okay, then what questions did you give in interview?
- lokar 3y ago
  I personally did a lot of system design, debugging (systems or code), or deep technical dive (explain in more and more detail how something works and why it works that way).
01100011 3y ago
I only interviewed once with them, but there wasn't anything I'd consider leetcode. There was a rather aggressive interviewer who drilled me on an architectural web services question despite interviewing for a systems programming position on Fuchsia and having a resume solely in embedded/systems programming. From my limited experience I'd say the interview process is broken, but not in the way people on here think.

pompino 3y ago

Ironically, many of their software products are bloated and slow as fuck. (There are some that are top class too, but just sayin.. )

trogdor 3y ago
>many of their software products are bloated and slow as fuck Which? I regularly use Gmail, Maps, Drive, Docs, Sheets, Home, Voice, and Takeout. I don’t think any of those are bloated or slow, but maybe I’m missing something. I’m also curious which you think are top class.
- pompino 3y ago
  The ones I think are top class are not really end-user oriented, it's core stuff like the search engine, their JS engine, etc. (IMO) The bloated ones are their webapps that suck up gigabytes and gigabytes of ram and CPU resources (client side) for basic stuff like showing you one couple of pages of emails or playing a video file.

summerlight 3y ago

Unless you're willing to spend more than 20~30% of your engineer's precious time on the hiring process (or have GPT-7 or whatever GAI lol), it will always be BS. And that's not scalable; this could work when your hiring is mostly through employee's personal/professional network since ROI will be better than average, but when you need to hire thousands new employees it will quickly become a bottleneck. The only thing you can do is designing an acceptable level proxy done with high efficiency. Unfortunately we don't really have a good way there to figure out something more efficient than coding interview + system design interview yet. A good interviewer can still extract a surprising amount of valuable signals within 45 mins but not everyone is interested in being a good interviewer.

heads 3y ago

As I’ve grown more senior in age and rank I’ve come to realise just how important it is to carry on the selection process after the interview, during probation, and managing performance throughout your hire’s entire journey. It just feels so incredibly imprecise relying on a few hours of meetings to gauge if someone is good or not, and the probationary period is crucial for correcting mistakes. Frankly, we also can’t afford to say no accidentally to someone who would turn out to be a great hire. I’m seeing this now through the lens of hiring at a 100 person org, but I’ve done hundreds of interviews as a FAANG employee too. The difference there, I would say, and what GOOG try to do is to shoot for the moon and get hiring nailed at the interview process. This comes at the expense of rejecting nine out of ten candidates because the candidate firehouse is free flowing and plentiful: something I don’t have at my much more normal startup.

ken47 3y ago
I’ve don’t think I’ve ever seen engineers complain about the rejection rate of Google’s interview process. The more common criticism/meme regards the laziness of running candidates through a unidimensional leetcode gauntlet. Half joking, but why even have engineers run these interviews at all? A proctor could get the same job done at a fraction of the cost. If a proctor can run the interview process, then how valuable is the signal?