61–70 of 157 posts
Earlier quoted context omitted.
> entertaining offers for remote (Canada) work. want to add an email or something to your HN profile :-)
Is it not visible? It's there. Don't see an option to make it public.
Earlier quoted context omitted.
Engineering culture at Google is vastly different than Amazon. Even Facebook which is more product oriented and iterates faster than focusing on the "right engineering design" first.
FB and Google engineering is basically identical in culture.
* Really practice open/active listening and critical thinking: there are very smart people and it's really good to assume good intent when they talk. Critical thinking and question is more around 'where is the disconnect? How do I try and actively move towards and see their point of view'.
* Questioning authority and being able to say no.
* Don't use code reviews as a debate forum but instead as a learning forum. Granted time is of essence, so a timely resolution may be necessary but learning and actively listening through reviews helps your skills as a coder.
* Cut through heirarchy and organizational politics to achieve the larger goals for the team, the project and ultimately for Google.
Earlier quoted context omitted.
> entertaining offers for remote (Canada) work. want to add an email or something to your HN profile :-)
Is it not visible? It's there. Don't see an option to make it public.
Earlier quoted context omitted.
Well, it depends. If you have an API with only a few direct usages, you might do it in a single commit. Changing API's that have many usages is difficult to do atomically even if you have a monorepo, due to the difficulty of getting approvals and the risk you'll have to roll it back. Often it's better to introduce a new function and migrate usages to it across multiple commits. Either way, it's on you to fix everyone…
In Chrome, more often than not it happens in one big commit.
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…
Absolutely disagree, to the maximum possible extent. My entire job at Google was to find and fix inefficiency in other people’s projects. I didn’t own any projects! But I submitted changes to foreign code daily and I rarely got any kind of pushback. 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 tha…
I am guessing that your changes did not change the semantic behavior of other people's code. e.g. you were replacing one hash-map implementation with a more efficient one. That's something where obviously Google's tools do cancel out the inherent inefficiency of large organizations/code bases.
My point was that Google has the level of efficiency of a small organization, despite being a large organization. That the default for big organizations is to "just suck" as you described, makes this remarkable, but I never felt like this resulted in a superhuman level of productivity that you might expect considering how advanced the tools are.
Earlier quoted context omitted.
Ah, okay. Pay scale, got it. Yea we have similar. Just no actual titles.
It's not just about pay, it's also about scope and expectations.
You can hide your level such that other people don’t see it, which is another difference between Google and my current company where people introduce each other by their titles, which makes me want to quit every time. Nobody at Google has ever said “And now I’d like to turn the meeting over to Principal Engineer Jane Doe”. Most people don’t mention it.
Earlier quoted context omitted.
What does "promoted" look like for an software engineer at large tech companies? In my company you're either an individual contributor or tech lead. There aren't really any other rungs on the ladder without going to manager.
Which sucks. Having a technical ladder is important to retain talent and ensure that you maximize the skills your talent pool has. Pure engineering skills (even the thought leadership aspect of it) doesn't directly translate in management skills and often people get "rewarded" by promoting them to a position where they can no longer use the very skills they have been promoted for. Related concept / good read: https:/…
Not Google, but another Big Tech company. 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 p…
Alternatively, one can negotiate the desired level/salary when starting a job so you can ignore the politics at least for several years, right? Or is it as well easy to be demoted (without politics)?
Other than having “Google” on my resume there is nothing special or applicable outside of Google. Most tools are internal, isolated and the choices are restrictive. Management is shitty - micro-management is in full bloom, display lack of management knowledge, skills and there’s plenty of abuse of power. They don’t show their appreciation to what we do. All developers are very competitive. My entire time of over a ye…
But yea, things are not always rosy and maybe Google indeed isn't the right fit.