Huh. This is worse in several respects than when I interviewed successfully in 2014. My own experience was frustrating in similar ways to this. Google didn’t respect my time. The process involved a lot of luck and a lot of uncertainty. The people running the process from Google’s side quit and were replaced by new ones, several times. The whole thing dragged out for no reason that I ever got a satisfactory explanation for, taking a total of four months. Had I not had friends already working at Google, I am certain I would have given up. Yet, this article describes a process even more opaque and bizarre than what I went through.
Unfortunately, the engineers giving interviews have very little visibility into what the process is like for applicants. I never felt it was fair to take any of the applicant’s time asking about that, purely to satisfy my own curiosity, but perhaps I should have. Similarly, hiring managers also don’t really get much of a look into what the applicant is going through. That was true in 2014, and from everything I’ve heard it had been true for many years before.
Google has had significant executive turnover in the organization it calls PeopleOps, in the last five years. So it’s not surprising to me that things have changed. It is, however, deeply distressing to learn that the deeply broken process I experienced has gotten worse, not better.
The whole story reads more like a hazing ritual than a search for competent software engineers, to be honest.
I think Google’s strategy is more focused on appearing like they “only hire the smartest”, such that potential developers self-(de)select themselves, than having an actual, working hiring process that selects competent candidates.
The tech company interview process is designed to:
Have a huge random factor to filter out qualified candidates
Select for people who specifically study for the interview
1 is for developer marketing, to maintain the image that you have to be the best to work there. 2 is because the majority of programming work is brainless and easy, so they want to hire people who will work on stuff for free just because you ask them to.
You also have to consider that the main sources of income for tech companies are tax evasion/lobbying/ads/VC money and not tech, so engineering competence is not really that important.
Hearing about stuff like this is why when I hear that somebody has worked at GOOG or others I’m not automatically impressed or intimidated.
Also, I am curious what the internal codebase of a such a place looks like when they seem to optimize for hiring folks with theoretical knowledge who don’t value their own time. After a couple of decades of this, it’s probably not pleasant to work in.
Oh, it’s extremely pleasant to work in, as long as it’s what you like. The tooling is amazing compared to anything on the outside. People with theoretical knowledge who don’t value their own time, tend to rabbit-hole on building the most elegant solution to the general problems they’re facing - and a lot of people at Google have successfully built those solutions, which lets everyone else benefit. Developer time may not be the metric that the tooling optimizes for, but developer comfort is amazing.
That said, there’s rough edges everywhere that nobody has time to fix. Almost everything is maintenance work in an existing project, so if you aren’t experienced at working in a codebase that’s too large to fully understand, good luck. Deploying something to production also has a lot of hurdles that would not exist in a smaller organization; I believe those hurdles are there for good reasons and shouldn’t be eliminated, but it’s a fashion of working that many people wouldn’t enjoy.
Sure, me, too. I guess what this meant was “The tooling is amazing compared to anything on the outside [for what I’ve seen]”. Maybe even “[compared to the five other big tech companies that I worked for]”. Or whatever your experience is.
It seems like nit picking but I think it is important not to put Google on that pedestal. And in my experience the tooling is nowhere as good to believe this is true. But I guess it also depends on what is important to you. There is some amazing infrastructure at Google for sure but I had to use terrible tooling as well which was easily bested “outside”.
I’d even say, it is easy to get a much better development experience for me than I had at Google for a small company setup. It will just nowhere scale as good.
“Anything” was certainly an over-statement. I think it came off like I was saying something stronger than I meant to; I was trying to compare against what’s generally available in open-source communities, not against other companies with similar levels of resources.
It’s also true that a lot of Google’s fancy tooling is meant to solve problems that nobody smaller than them has, because those problems only arise at scale.
I do agree that it’s important not to put Google on a pedestal. I will certainly agree that, even comparing to what’s available in open-source land, nothing at Google is so dramatically better that we should give up on ever matching it.
The codebase is in decent shape overall, especially considering its size & age. Thanks to having a monorepo & some very impressive tools for refactoring at scale, plus a willingness to constantly deprecate stuff even if it’s painful, the code stays in good shape even when nobody even works on it anymore!
“You can pass every interview with A grades and still not get a job, because a senior Googler decides that you’re the wrong person to be hired.”
While this is technically true, it is very rare in practice.
“the results would be ready only after a week and a message to the recruiter.”
That’s rampant & it’s totally not the recruiter’s fault. It’s interviewers (myself included) who take days to submit the interview feedback. It’s just not a very enjoyable experience to do that so it’s easy to put it off until a recruiter asks about it. Part of this is that all engineers are required to interview whether or not we want to do it so not everybody is going to be equally enthusiastic.
“Google is just another big enterprise company that has all these bureaucracy problems, opaque processes and weird rules”
This wasn’t true in the past but has slowly been getting truer as the company expands. It’s hard to avoid it at 120,000 employees :-(
I just happened to be listening to Ride of the Valkeries as I was reading. First off, +1 to you ilyap. You did your best and honestly you probably did better than most.
But man, reading the experience makes my stomach ick. I’m glad you’ve chosen to come to the contractor side. It’s cozy here.
When I read “George told me to improve my Big O and graph theory skills” I just died. At least the way you present yourself, I’m pretty damn sure you’d be able to do any graph theory related problem if need be. Choosing 2048 though as the graph theory problem is just … what. Like what?… I don’t understand. Is this an interview process for a day to day software engineer or someone who sees in theories and structures?
Google really is looking for certain individuals - and it doesn’t stop at “breathes code”.
The process is optimised to find people who are compliant. Willingness to learn difficult trivia or questionable use, and jump through pointless hoops, is ideal for that purpose.
The last thing management wants is labor that talks back - look at how they come down on staff who attempt to unionise.
I feel like that filter will result in strong bias against candidates that are normally seen as very attractive - those that are working hard at their current position but looking for a change.
Google makes money regardless of whether their staff are amazing - the income is derived from tech that’s already been written.
In that context, a competent but disobedient candidate who does what they think is right would be a truly dangerous hire. They might make it harder to run the core profit-making enterprise.
Much safer to filter for moderate competence and high obedience.
Indeed, in the 8.5 years I’ve worked at Google building software I think I’ve had to solve an interview-calibre algorithmic problem maybe thrice. Mostly we write plumbing to move protos around.
Applying to Google can be a great learning experience. But it’s too much work if you’re simply looking for a job. There are zillions of fine companies that don’t make you jump through hoops for three months before giving you a clear answer.
Yeah, I think I’m really glad I decided not to go down that route. I would not have gotten anywhere near as far (even as someone who practically breathes code and has been doing this for quite some time…), and trying to get myself to a place where I might have been able to would have just been frustrating quite frankly.
Huh. This is worse in several respects than when I interviewed successfully in 2014. My own experience was frustrating in similar ways to this. Google didn’t respect my time. The process involved a lot of luck and a lot of uncertainty. The people running the process from Google’s side quit and were replaced by new ones, several times. The whole thing dragged out for no reason that I ever got a satisfactory explanation for, taking a total of four months. Had I not had friends already working at Google, I am certain I would have given up. Yet, this article describes a process even more opaque and bizarre than what I went through.
Unfortunately, the engineers giving interviews have very little visibility into what the process is like for applicants. I never felt it was fair to take any of the applicant’s time asking about that, purely to satisfy my own curiosity, but perhaps I should have. Similarly, hiring managers also don’t really get much of a look into what the applicant is going through. That was true in 2014, and from everything I’ve heard it had been true for many years before.
Google has had significant executive turnover in the organization it calls PeopleOps, in the last five years. So it’s not surprising to me that things have changed. It is, however, deeply distressing to learn that the deeply broken process I experienced has gotten worse, not better.
The whole story reads more like a hazing ritual than a search for competent software engineers, to be honest.
I think Google’s strategy is more focused on appearing like they “only hire the smartest”, such that potential developers self-(de)select themselves, than having an actual, working hiring process that selects competent candidates.
The tech company interview process is designed to:
1 is for developer marketing, to maintain the image that you have to be the best to work there. 2 is because the majority of programming work is brainless and easy, so they want to hire people who will work on stuff for free just because you ask them to.
You also have to consider that the main sources of income for tech companies are tax evasion/lobbying/ads/VC money and not tech, so engineering competence is not really that important.
Hearing about stuff like this is why when I hear that somebody has worked at GOOG or others I’m not automatically impressed or intimidated.
Also, I am curious what the internal codebase of a such a place looks like when they seem to optimize for hiring folks with theoretical knowledge who don’t value their own time. After a couple of decades of this, it’s probably not pleasant to work in.
Oh, it’s extremely pleasant to work in, as long as it’s what you like. The tooling is amazing compared to anything on the outside. People with theoretical knowledge who don’t value their own time, tend to rabbit-hole on building the most elegant solution to the general problems they’re facing - and a lot of people at Google have successfully built those solutions, which lets everyone else benefit. Developer time may not be the metric that the tooling optimizes for, but developer comfort is amazing.
That said, there’s rough edges everywhere that nobody has time to fix. Almost everything is maintenance work in an existing project, so if you aren’t experienced at working in a codebase that’s too large to fully understand, good luck. Deploying something to production also has a lot of hurdles that would not exist in a smaller organization; I believe those hurdles are there for good reasons and shouldn’t be eliminated, but it’s a fashion of working that many people wouldn’t enjoy.
That’s a strange statement. How would you know?
I was impressed with some tools but generally my job involved a lot of waiting for unnecessarily slow tooling.
Some of us have worked at several other places before Google.
Sure, me, too. I guess what this meant was “The tooling is amazing compared to anything on the outside [for what I’ve seen]”. Maybe even “[compared to the five other big tech companies that I worked for]”. Or whatever your experience is.
It seems like nit picking but I think it is important not to put Google on that pedestal. And in my experience the tooling is nowhere as good to believe this is true. But I guess it also depends on what is important to you. There is some amazing infrastructure at Google for sure but I had to use terrible tooling as well which was easily bested “outside”.
I’d even say, it is easy to get a much better development experience for me than I had at Google for a small company setup. It will just nowhere scale as good.
“Anything” was certainly an over-statement. I think it came off like I was saying something stronger than I meant to; I was trying to compare against what’s generally available in open-source communities, not against other companies with similar levels of resources.
It’s also true that a lot of Google’s fancy tooling is meant to solve problems that nobody smaller than them has, because those problems only arise at scale.
I do agree that it’s important not to put Google on a pedestal. I will certainly agree that, even comparing to what’s available in open-source land, nothing at Google is so dramatically better that we should give up on ever matching it.
Yeah, different set of needs. Now I’m curious about what you had to use. Mind PMing me?
The codebase is in decent shape overall, especially considering its size & age. Thanks to having a monorepo & some very impressive tools for refactoring at scale, plus a willingness to constantly deprecate stuff even if it’s painful, the code stays in good shape even when nobody even works on it anymore!
“You can pass every interview with A grades and still not get a job, because a senior Googler decides that you’re the wrong person to be hired.”
While this is technically true, it is very rare in practice.
“the results would be ready only after a week and a message to the recruiter.”
That’s rampant & it’s totally not the recruiter’s fault. It’s interviewers (myself included) who take days to submit the interview feedback. It’s just not a very enjoyable experience to do that so it’s easy to put it off until a recruiter asks about it. Part of this is that all engineers are required to interview whether or not we want to do it so not everybody is going to be equally enthusiastic.
“Google is just another big enterprise company that has all these bureaucracy problems, opaque processes and weird rules”
This wasn’t true in the past but has slowly been getting truer as the company expands. It’s hard to avoid it at 120,000 employees :-(
I just happened to be listening to Ride of the Valkeries as I was reading. First off, +1 to you ilyap. You did your best and honestly you probably did better than most.
But man, reading the experience makes my stomach ick. I’m glad you’ve chosen to come to the contractor side. It’s cozy here.
When I read “George told me to improve my Big O and graph theory skills” I just died. At least the way you present yourself, I’m pretty damn sure you’d be able to do any graph theory related problem if need be. Choosing 2048 though as the graph theory problem is just … what. Like what?… I don’t understand. Is this an interview process for a day to day software engineer or someone who sees in theories and structures?
Google really is looking for certain individuals - and it doesn’t stop at “breathes code”.
The process is optimised to find people who are compliant. Willingness to learn difficult trivia or questionable use, and jump through pointless hoops, is ideal for that purpose.
The last thing management wants is labor that talks back - look at how they come down on staff who attempt to unionise.
Yeah I didn’t want to say it, but you pretty much took the words outta my mouth. :)
I feel like that filter will result in strong bias against candidates that are normally seen as very attractive - those that are working hard at their current position but looking for a change.
Google makes money regardless of whether their staff are amazing - the income is derived from tech that’s already been written.
In that context, a competent but disobedient candidate who does what they think is right would be a truly dangerous hire. They might make it harder to run the core profit-making enterprise.
Much safer to filter for moderate competence and high obedience.
Thank you!
I had really fun in my interviews.
It was somewhat disappointing that there were not really challenges like that when I started working.
Indeed, in the 8.5 years I’ve worked at Google building software I think I’ve had to solve an interview-calibre algorithmic problem maybe thrice. Mostly we write plumbing to move protos around.
Why is rant about someone’s interview experience at google tagged ‘programming’?
For example, this has nothing to do with programming:
‘rant’ and ‘practices’ seem like better tags for this, if it’s not off-topic altogether.
Applying to Google can be a great learning experience. But it’s too much work if you’re simply looking for a job. There are zillions of fine companies that don’t make you jump through hoops for three months before giving you a clear answer.
Yeah, I think I’m really glad I decided not to go down that route. I would not have gotten anywhere near as far (even as someone who practically breathes code and has been doing this for quite some time…), and trying to get myself to a place where I might have been able to would have just been frustrating quite frankly.