11–20 of 157 posts
They don't cancel each other out exactly though, so some things are way easier (spinning up a huge computation), while some things are way harder (making a small change to shared components).
Visibility is very important to getting a promotion at a large company. Selling your work is important.
To move up, you must be playing the "choose a good project or team" game for at least 6 months before you try to get promoted. Preferably for a year or more to hit the right checkboxes for multiple cycles.
If you fail to do so, you can do absolutely amazing work but rigid processes and evaluation criteria will conspire to defeat you in a promotion committee setting.
At least, that's true in my company. From my ex-Google peers it seems to be true there as well.
Being in a smaller office means you get fewer of the best projects available to you. Reorgs sometimes steal them. Cancelling projects makes the last half a waste of time from a promotion standpoint.
As for what constitutes a good project. It will:
* Let you lead it
* Have peers at your level + one or two
* Work with multiple other teams
* Ideally work with multiple teams outside of your group, e.g. you're in, say, a chat app team and get to solve issues for some other app
* Good product manager and designers with a well thought out product; it's not fair, but if the project is successful business-wise people will often incorrectly attribute that to your own skills
* Have large engineering scope. Committees get confused and sometimes think simple designs to solve complex problems are bad. You want to solve problems that are complex even in terms of the solution (or can be made to sound complex) to check more boxes.
* Allows you to solve problems for other teams
I haven't optimized for promotion and thats personally hurt me in the quest to get to L6. I very, very close but didn't quite make the leap.
Don't ignore the flaws in this committee process. Exploit them.
Don't be me.
You should replace Google with "big tech company" or FAANG to get more responses.
FAANG don't share the same engineering culture.
It’s a very miserable monoculture.
That’s why I changed my view on who was the key person for google success. I used to believe Larry and Sergei, then urs, now I put on Laszlo Bock.
What I haven't learned: how to thrive in a huge organization with people more bureaucratically ambitious/motivated than you. How to turn a blind eye to broken waterfall method dysfunction. Starting to get to me. Probably looking for the door soon; p.s. entertaining offers for remote (Canada) work.
Everybody comments about how there are all these amazing tools that help your productivity (which is true), but they don't talk about how the opposing force of organizational complexity ultimately results in "just normal" levels of productivity. They don't cancel each other out exactly though, so some things are way easier (spinning up a huge computation), while some things are way harder (making a small change to sh…
Working on shared code is so easy at Google because they have a fantastic cross-referenced code browser and search engine, ways to inspect production jobs and configs that anyone can access, and everything is open and visible.
By contrast the other large publicly-traded cloud company where I now work has the opposite culture: no code search worth using, “why are you touching my project?” culture, not enough tests to give anyone confidence in a change. The polar opposite of Google.
Everybody comments about how there are all these amazing tools that help your productivity (which is true), but they don't talk about how the opposing force of organizational complexity ultimately results in "just normal" levels of productivity. They don't cancel each other out exactly though, so some things are way easier (spinning up a huge computation), while some things are way harder (making a small change to sh…
The biggest thing I grew to appreciate was that for iterating large scale production systems, rollout plans are as important as anything else. A very large change may be cost or risk prohibitive to release at once, but with thought you can subdivide the release into easier to rollout and verify subcomponents, you can usually perform the same work as a series of lower risk well understood rollouts. That's critical enough where it's worth planning for this from the design phases: much as how you may write software differently to allow for good unit tests, you may want to develop systems differently to allow for good release strategies.
Google is a large company, and I think there are software engineers learning very different things from what I focused on. I worked on large scale machine learning in ads; someone working on chrome or Android likely learned very different things.