My google interview was the best part of the whole time there to be honest. If the work had lived up to the people and problems presented in the interview, I would still be there, happy as a clam.
Instead, it was a complete forced bait and switch onto a team doing something irrelevant to my skill set, which is my way of saying there are plenty of problems with Google, but this is not one of them.
I've heard this a couple times now, and it worries me. I've got an on-site interview with Google soon, and my impression from the recruiter is that I would know which team I was joining at the offer stage.
Can you go into some detail on what happened between your offer and joining Google that resulted in you feeling like it was a "bait and switch"?
If it matters, I am not interviewing as a college hire, but as a senior engineer from another large tech company.
[I apologize in advance, I think I got a bit snarky there at the end]
Historically Google doesn't allocate jobs and then hire to them, rather they hire and then from the accepts various managers 'bid' on those candidates to fill their needs. Clearly I am a bit biased as I joined Google as a 'senior' guy, and went through this stuff, spent four years there, and now I don't work there any more. Its not for the faint of heart.
The reasoning for this is that smart people can do "any" job[1] and the when people join Google its so "different" than any other culture that your first assignment really won't matter anyway. The theory is you accept, they throw you into some random job, you get evaluated (used to be this was when your job level was also determined) and then you are expected to know what you want to work on, move there and work on it.
This system is especially hard on senior folks, it works ok on new college grads. As a senior engineer you can be assigned to write shell scripts that take the output of one program and make it input to another, or clean up performance issues in a code written by someone who had no idea how to write performant code. You are almost assured of landing on a project where the original developers of it have collected some 'cred' for "shipping" it after getting it 90% done and have moved on to something else. It will be the biggest waste of your time that you could imagine.
The good news is that if you survive that gauntlet then your next assignment will be to get yourself out of the cesspool you landed in and into a project that you care about. The bad news if you don't create as much code as the young guy who is in the cesspool next to you but does his laundry at the 'plex' and eats three meals a day there, then your not going to do well on your evaluation. A good defensive strategy there is to do several side projects with folks at Google to build up a 'yeah he's a good guy' kind of relationship with folks on the committees. That way when the question of how many kLoc you produced comes up relative to your live-at-work cube mate your friends on the committee can counter the negative remarks with 'but hey, he's a really great guy.' which will help.
Now that you're successfully "in" learn to fail fast, go through a bunch of projects looking for one that will show up on the radar of some influential (low employee #) folks, there is a great tool called 'percent' that tells you how many folks joined after someone, you want to cultivate the 99.9 percenters. They will always be on the various committees that will be evaluating you at some point and you want them to both know who you are, and have a positive impression. Shine their shoes as they say. If you're an academic many of the tools you used to get your grant money, grad students, or onto the front of the author list on papers will serve you well here.
Once you've reached a level of credibility that your "calibration" score is pretty much not going to get knocked down because some early employee is pissed off at you, start thinking about what sort of problems you would like to work on. Go look for them and get yourself on the project, do the fun stuff (the wild designs, the crazy idea papers, the mocks, the prototypes) get it to the point where it works enough that it is clear it will actually work if someone finishes the code, "ship it" and take the credit, relish in your big bonus that year knowing that some new hires will be dummped into that project, now that you've moved on. to make it work. Not your problem any more, you're on to bigger an better things, your a Googler!
[1] I think of this as the 'fallacy of fungibility' where any employee can be moved to any job, when in fact depending on fit they may do well or poorly unrelated to their skill set.
And this is just it, I was indeed senior level. I do not have the patience to play a cultural game internally just to get to a project that makes use of my skills. My bad.
If that makes me a bad cultural fit, G O O D! If a company isn't smart enough to pair me with a problem I am adept at solving, then plenty of other companies are, and that's why I left after only 4 months. Got a raise too.
Google's hiring process is toxic[1]. It's probably costing them big bucks that they can't quantify properly as a line item in their budget so they probably won't consider changing. All I know is that whenever I recount my days at google on HN, lots of people upvote my story, a lot. I suspect others have similar tales to tell.
[1] Not that other companies don't have their own personal poisons, but yeesh, why not try something new once in a while?
I had an interesting conversation with Alan Eustace (who was in charge of engineering at the time) about this. We had just hired, abused, and lost a guy who had been the CTO of his previous company, got hired in and forced to clean up message catalogs in i18n code, and quit after the slotting committee decided he was really 'junior engineer' level and should be put on a performance improvement plan so that he could learn to "step it up."
I don't know how common his situation was, I was fairly outspoken (no surprise) and he had reached out to me early on when he was trying to figure things out. The PIP (which is basically a pre-cursor to being fired) basically put him over the edge, and he quit. The sad thing was of course this guy was really smart, had excellent design sense, and knew more about the way Java worked than I did and I was one of the original developers of Java at Sun! A real top notch kind of guy.
He had been caught in the 'perfect storm' of which there were many, of a manager whose project was strategic to the company and understaffed, a skillset that waaay out ranked his assignment, so even doing perfect work it wouldn't begin to show his capabilities, and a 'peer review' system that primarily tested social engineering skills rather than technical skills. Everybody lost. He lost his job, Google lost a great engineer, the system lost an opportunity to improve.
The essence of the discussion with Alan boiled down to "Its a complex system and its going to have some failures, but by and large it works well so unless you can come up with something better we're stuck with it."
So in some ways the interview process is a good test to see if you might be the kind of person that would do well at Google.
Well, given that I aced the interview (plenty of evidence besides the job offer I got within 24 hours of it and some of it I probably shouldn't know but I do), I should have been a wonderful fit then, no?
Tell ya what, how about trying one of those infallible(tm) A/B tests where half the incoming people get the Hogwarts hat and the other half get to meet their team upfront before accepting a job? Do this for a year. Now one year after that measure which set of employees is happier/present/more successful.
That does sound a bit jaded, yes, although I completely agree on the fallacy of fungibility. It's a trait shared by my current employer as well, though, so I don't feel I'll be any worse off on that front.
I'm still likely to make the jump if they make me an offer that's a decent bump where where I am now, but I suppose that's because I'm a bit jaded myself.
Well I can completely recommend working for Google as a way of helping to calibrate what you will or won't do for a 'decent bump' :-)
To its credit there are lots of great people there, and the parts that work well are insanely amazing. I marveled at how you could have both the best and worst day of your career on the same day at Google. My failing is that I tend to care too much about problems that aren't going to be solved.
Was the percent tool written with cynical intent? Or was it a simple in-joke, perhaps, among longstanding members of staff amazed at Google's growth? I'm not really sure what, if anything, I should read in to the tool's existence...
I don't think there was any cynicism in the creation of the percent tool, it was a way to see how fast the company was growing. Although when you thought about it you could draw interesting insights from the data, for one if you used it on yourself you would see the number of people hired after you growing fairly rapidly, more rapidly in fact than the total number of employees was growing. From that piece of information you could ascertain the 'stick' rate of hires, which is how many people stayed around for 3months, 6months, a year, 2 years, 4 years. All the usual peaks and valleys.
A lot of people interview thinking they are going to work on Google Glasses and then get allocated to corporate IT. You don't know your role at the company until the day you start.
Yes, I suppose what I'm looking for is where exactly things go awry.
Again, the impression I'd gotten from my recruiter is that I'd have more or less a commitment from Google that I'd be working on a particular team at the offer stage. In particular, that I'd know which team I was going to work on when I accepted the offer.
So it seems like either she's exaggerated that (in which case I would expect it to seem fairly obvious at the offer stage that you weren't yet assigned to a team), or that Google is in the habit of outright lying about team assignments, which I have a hard time buying.
For me, allocation, period. For all the investment made by Google in hiring me, and all the personal debt I accrued in leaving my previous employer and renting an apartment in Mountain View, it all came down to getting hosed by Google's version of the Hogwarts selection hat.
All attempts to address this were blocked by mid-level management, leaving me no other options other than continuing a job I hated or leaving. Even engineers within google who had worked with me in the past and vouched for me couldn't make a difference.
Google's allocation process is akin to Russian roulette and I got the chamber with a bullet in it.
So I left.
Now there is hope. Just like Jamba Juice lets you order off-menu smoothies, Google will let you pick what you want to do if you can find a team that will accept you. They just don't talk about it. Insist on it and I suspect you'll be fine. I wish I'd known that bit before I went there.
My experience interviewing with Google (a couple of times in the last 3 years) is full of what can be considered "riddles". They weren't obvious riddles, but where questions "to know in advance", specially considering the short amount of time to answer them.
The second time I got quite frustrated about that, specially on the last one after doing a couple interviews before that I was happy with the kind of questions I was asked (relevant and intelligent), so I'm not probably going to give attention to Google recruiters any more.
there are definitely questions where you have to think of the right general algorithm and datastructure very quickly, and then spend your time refining it for the details of the problem, but i'd argue that that's not in the same "aha!" class as actual riddles.
Well, knowing the O performance of some sorting algorithms, is not what IMHO can be defined as "we want to know how you think". Or implement, in a very short amount of time, tree algorithms.
I mean, they are not totally 'aha!' things, but they are the kind of things that you could nail one day, and be completely stuck another. And quite irrelevant to your work (as is highly unlikely that you'll ever implement it)
On the other hand, questions about how and why to use this data structure or another, are totally relevant and interesting. And shows way more that you have been using them and know what are the differences.
Again, is just my opinion (and Google can do their interview process as they like, they are obviously doing fine in getting a great team!), but my impression is that gives a lot to chance or inspiration in some interviews, and giving their process, one mistake could be all you need to be out.
My google interview was the best part of the whole time there to be honest. If the work had lived up to the people and problems presented in the interview, I would still be there, happy as a clam.
Instead, it was a complete forced bait and switch onto a team doing something irrelevant to my skill set, which is my way of saying there are plenty of problems with Google, but this is not one of them.