Live data from Hacker News

Software Engineering at Google

arxiv.org

121–130 of 161 posts

Re: Software Engineering at Google

#121

I read most of the paper. For the most part, it struck a nice tone as being mostly descriptive and not too promotional. However, the final paragraph in the conclusion section differs: > "For those in other organizations who are advocating for the use of a particular practice that happens to be described in this paper, perhaps it will help to say “it’s good enough for Google”. In my opinion, this style of writing does…

With one-or-two exceptions, what the paper describes is very familiar and sounds like most software teams, but most teams don't achieve Google-like performance/stability/success.

The differentiation is in details that the paper doesn't explore.

I agree, this paper will just lead to more monolithic Git repos "because it's good enough for Google", without the appreciation of Google's other tooling and processes.

Re: Software Engineering at Google

#122
post #107

Earlier quoted context omitted.

Blind allocation? When I joined Google I was given 4 teams in 2 different locations to choose. I had lunch with each of the teams, and chose the one that better suited my style. To be fair, your experience at Google will depend a lot on what team you land in. Not everyone's given a choice, but now I know better: Talk to your recruiter and make them clear what you want.

Sure, that would be great, but as a result of leaving, I have been blacklisted by HR from ever returning. And the one guy that tried to bring me back in a year ago met in the lobby of his building and then walked me out to the marsh behind the GooglePlex before saying a word to me. I then asked if I could use said technology for which I am a recognized expert, he said no, and that was the end of that. I have been tem…

People aren't blacklisted for leaving, that's blatantly false. Your story is obviously missing some key elements.

Median tenure does not necessarily indicate retention issues for core roles at any company. It could simply be rapid growth or lots of roles that typically come with high turnover (e.g Amazon's warehouse employees).

Re: Software Engineering at Google

#124

Earlier quoted context omitted.

Sure, that would be great, but as a result of leaving, I have been blacklisted by HR from ever returning. And the one guy that tried to bring me back in a year ago met in the lobby of his building and then walked me out to the marsh behind the GooglePlex before saying a word to me. I then asked if I could use said technology for which I am a recognized expert, he said no, and that was the end of that. I have been tem…

People aren't blacklisted for leaving, that's blatantly false. Your story is obviously missing some key elements. Median tenure does not necessarily indicate retention issues for core roles at any company. It could simply be rapid growth or lots of roles that typically come with high turnover (e.g Amazon's warehouse employees).

Indeed, "blacklisted for leaving Google" seems pretty far-fetched. In reality people who leave Google with reasonable performance ratings have the option to return within 6 months after they leave.

Re: Software Engineering at Google

#125
post #96

Not one word about what I consider the most toxic aspect of working at Google: blind allocation. Unless one absolutely does not care what one wishes to work on, joining Google is throwing your future into the Hogwarts hat of an ill-defined cabal of billionaires to pick your job at Google. Sometimes that works out, but most of the time you are allocated to whatever mission-critical project is currently leaking buttche…

The above like appears to be based on using tenure of current employees to measure "retention". So that is going to heavily skew low for companies that are growing, which makes it unsurprising that Kodak has the best retention and growing tech companies are generally low.

So I wouldn't put much stock in that as a meaningful comparison.

Re: Software Engineering at Google

#126
post #107
post #96

Not one word about what I consider the most toxic aspect of working at Google: blind allocation. Unless one absolutely does not care what one wishes to work on, joining Google is throwing your future into the Hogwarts hat of an ill-defined cabal of billionaires to pick your job at Google. Sometimes that works out, but most of the time you are allocated to whatever mission-critical project is currently leaking buttche…

Blind allocation? When I joined Google I was given 4 teams in 2 different locations to choose. I had lunch with each of the teams, and chose the one that better suited my style. To be fair, your experience at Google will depend a lot on what team you land in. Not everyone's given a choice, but now I know better: Talk to your recruiter and make them clear what you want.

That's interesting. When did you join, and where? There was no such option in 2011; you just ended up wherever you ended up, and were expected to make the best of it.

Re: Software Engineering at Google

#127
"Most software at Google gets rewritten every few years" at incredible expense. That sounds crazy, but the article claims it has benefits including keeping up with product requirements, eliminating complexity, and transferring ownership. Would be interesting to see some kind of metric indicating how much of an outlier Google really is here, and what measures it takes to make sure rewrites aren't worse (second system).

Re: Software Engineering at Google

#128
post #20

Earlier quoted context omitted.

In my experience, yes. Most people find it courteous to inform their manager but I did a lot of 20% time that led to getting hired with Google Brain, and it was never any doubt in my mind that my manager would approve. That being said, there were times when I was really excited about the project so I would work 80% time plus 40% time and stay late.

Can you tell us about what exactly you did that led you to getting hired with GB?

I don't want to get too specific but I did a 20% project that led to a couple of conference abstracts with one subteam. This built relationships which helped when I applied internally to work on a different subteam.

20% time aiding in team transfer is very common I think.

Re: Software Engineering at Google

#129

Earlier quoted context omitted.

Google is awesome if you can avoid the allocation problem, I agree. I was not given such options.

Could not you switch team while you were at Google?

People usually switch after a year and a half of being on a team, but not much different than that.

Re: Software Engineering at Google

#130
post #58

Google has gotten so large so quickly in the past 3 years, that I wonder how much damage has been done to their engineering culture. A lot of "less than stellar people" have joined in these recent years according to several of my friends that work there (in infrastructure and some ML groups). It seems the push to golang is entirely to sustain large projects with average engineers. Maybe somewhere high up they decided…

I've only been there 13 months but I've found the quality of previous and new hires are ridiculously high. Given the number of talented people applying every day I think Google could increase hiring by 100% with no appreciable drop in quality.

Google has a lot of imperfections addressed elsewhere in the comments here but the engineering culture is extremely strong and one of the best parts about being there. I think the overall "Googley culture" is suffering but it isn't for technical reasons.

Then again maybe I'm one of those C players who snuck in the past year.

Post reply on HN