|
|
|
|
|
by notmyhnname
4907 days ago
|
|
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. |
|
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.