Hacker News Reader

> It's easy to move. There is no pay difference no matter what project you work on and internal mobility is encouraged and supported. People do what they want to do, and they tend to be extremely motivated as a result. It also helps remove bad managers: sinking ships get abandoned really, really fast. This is arguably the company's greatest weakness as well as it's hard to get people to work on something soul-consuming. But it's great for the employees and it's great for innovation.

This is clearly both necessary if they want to retain their "all our people are among the best (and therefore have lots of options if they want to leave)" workforce and harmful to their projects. There's plain flakiness to their approach to things that's at this point a distinguishing characteristic of Google products. Even things that stick around long-term and don't get cancelled outright show heavy signs of no-one wanting to do the boring work, and no-one making them do it. Or of half-assing the boring work and then never fixing it.

There is a really strong counter-argument to this that "the boring work" doesn't really matter in the long-run.

I've seen many great projects sink over time because management over-indexes on easily understood, time consuming efforts, with only marginal customer impact. These efforts are easy to justify quarter on quarter - but are incredibly generic.

Great big products tend to emerge from driving repeatable improvements in something everyone needs e.g. search, content, recommendations, servers, networks, data etc. and solving the hard problems that no one else has the dedication to solve.

The problem arises when you as developer rely on this thing that Google invented but suddenly got bored of and shut down or changed a lot so your implementation has to be rewritten. Many have been hit by this over the years so are reluctant to try again.

There are counterexamples, though: https://news.ycombinator.com/item?id=16347083

As of last year, the last time I tried, the Google backed maps app still works on my first gen iPod Touch - last updated in 2009 and the first gen iPad.

I've been hit by this at least a half dozen times over my career. Apps scripts are probably the latest one causing me pain. I love being able to integrate with docs & sheets, but man if that ecma version isn't ancient af.

> man if that ecma version isn't ancient af.

It is incredibly ancient. It's possible to use Babel w/ it though, and write reasonably modern JS. There's a CLI tool out there to upload something into an Apps Script … app? too; at one point, I had a project w/ a Makefile that would run the project through Babel and then upload it to Google.

I didn't try all the features (and I didn't have any npm/package management), but things like format strings, for(… of …) loops, let/const, new Map() all worked. Babel is a wonderful, wonderful thing.

If it were simply ancient, that'd be one thing, but it's a weird hybrid of es3 with _some_ es5 features, and some es6 ones that often don't work the same. e.g. it has `const`, but no `let`, and it's not even block scoped so it's not that useful. Destructuring is there, but for arrays only and not object properties.

I built my babel config to balance clean, new syntax with the least intrusive transforms possible. e.g. I have loose template literals on, since `\`hello ${world}!\`` is an easy transform (and still readable in the final source) as `'hello ' + world + '!'`. Generators, for .. of, and object rest/spread, are okay, but babel puts a ridiculous amount of helper functions at the top to support this. I suppose I could always configure each project with a shim file, but that's extra overhead I really could do without.

block-scoping, arrow-functions, function-name, shorthand-properties, spread (for arrays and arguments), template-literals (loose, so `+` not `String#concat`), and exponentiation-operator I found give the most bang for your buck. `for .. of` is nice but if I can pass arrow functions into my `forEach` callbacks that's pretty clean too. Pretty great being able to say

``` rows.forEach(row => { const payload = row.map(([name, rank, serialNo]) => ({ name, rank, serialNo })); SomeApi.doThing({ onComplete() { foo(); }, payload, }); }); ```

in gapps. That said, it took a while to even figure out how much was possible, but yeah it's a big step up.

This is leaving out the effect of headcount restrictions, which is how management keeps overall control over what gets worked on. Sometimes there are legacy projects that have headcount but trouble filling it. But sadly, sometimes there are people who do want to work on some important maintenance project, but they can't get headcount.

So, it may be easy to move, but only in certain directions where management wants people to move.

(Or see if you can make a case for increased headcount somehow. Being good at persuasion or having a manager who trusts you can work.)

> There is no pay difference no matter what project you work on

I've heard that you'll get raises for working on new things. That's why Google launches so many new projects (and closes so many of those projects) and that's why old projects are constantly rewritten/redesigned instead of just imprpoving and bugfixing. I don't like it as a user, I want to use the same interface for 50 years and I want all bugs to be removed, rather than learning new interface and new bugs every few years.

You get promoted by shipping stuff (at least, when I was there). You get a raise by getting promoted. So there's an indirect connection between launching things and getting more money.

I think that the OP's referring to a phenomena at different big companies where certain divisions get paid more because management deems that division more important. That creates a dynamic where everybody tries to get into that division, and the ones that can't end up bitter, demoralized, and resentful (and hence unproductive). Connecting pay to tangible accomplishments rather than where you are in the company avoids that dynamic, though it does create the one you've observed where everyone is hunting for tangible accomplishments.

I'd say failure to align financial incentives is a bigger problem than jealousy of colleagues in the staff cafeteria. Zoom has crushed Google Hangouts and is now a $27 billion company, yet the Hangouts team are still rewarded with sweet Google stock options.

Arguably both alternatives lead to the big company getting crushed in emerging markets. If you pay for performance in hot emerging markets you cause resentment in all the other divisions, which leads to them underperforming (which is often a more dangerous problem, since this includes the slow-growing cash cow divisions that finance the fast-growing emerging markets). If you don't pay for performance, everybody gets complacent, and you miss out on new markets to hot new competitors.

I spent 5 years at Google hoping the intrapreneurship thing would work. AFAICT it doesn't, and eventually I came to accept Paul Graham's conclusion that big companies are constitutionally incapable of innovating and that's why he makes lots of money funding startups. In my observations the biggest problem isn't even compensation: it's that there are too many roadblocks to launching things and trying things out in a big company, too much incentive to be risk-averse, and too little feedback from the market itself with too much feedback from irrelevant decision-makers within the organization. The flip side of fixing those is that it radically increases both the failure rate and the rate at which the company pisses off outside people, both of which would be fatal at Google's scale.

IMHO the way Google does compensation is the best I've seen, it's just that "the best" will still result in good companies getting crushed by upstarts. So just accept that and try to create a good working environment while the company continues to print cash.

This is misleading.

It is true that people are rewarded for impact, which usually means new systems. But this does not necessarily mean new products from an external perspective. I know a lot of people who have been promoted really high based on stuff that they have led that has zero visibility to external users but ends up being worth oodles of money (or whatever metric you are trying to impact).

Zillions of product launches seems to arise from a combination of a largely bottom-up company with a ton of employees and a culture of building things themselves rather than using existing solutions.

> 1: The people are smarter.

I’d phrase this a little differently: the people there can be relied upon to at least have some “baseline” technical ability. Having worked at both FAANG and more mediocre companies, one thing that stands out is that while not everyone at FAANG are super-wizards, you’ll never have to sit there and explain things like “what is a stack trace” and “what happens when you write past the end of an array” and “what is the difference between O(n log n) and O(log n)”. You’ll never have to argue whether using source control is a good idea. You’ll never have people who spend weeks just trying to get Hello Project” to compile. All of which I’ve seen in other companies.

The big guys hiring processes might not be great but unlike most companies they seem to be able to filter out the complete know-nothings, and that alone is probably what raises the average.

TLDR: it’s not that they hire smarter people—they just avoid hiring way-below-average people.

I work at Google, worked at Amazon, and you nailed it. Most people at Google are far from coding superstars. But basically everyone is fairly smart, nice, and hard-working. I basically never come across any dead weight.

Does this apply to Amazon too? I’m not sure what you’re implying here.

That's funny, literally the only person I've ever had to explain a stack data structure to in my career was a Google alumni. He calls himself a "Chief Architect" now.

Google alumni != Google SWE.

He was a SWE

was

And therein lies the problem -- Google has been extremely successful at persuading itself and others that "can invert a binary tree on a whiteboard" is in any way synonymous with being "smarter". That's how we end up with at best people believing that ML will give us self-driving cars and at worst with all the societal problems that result from what these companies do, "but we just need to adjust that algorithm, train that model, and more, more, MORE of your personal data, and then we will lead the world to utopia" thinking. And they might even believe that.

Ed.: also appear to be very often very insecure about it.

> You’ll never have people who spend weeks just trying to get Hello Project” to compile. All of which I’ve seen in other companies.

I'd love to read the back story on this. Was it really a "hello world" project?

Don’t want to give details but let’s say it was highly reminiscent of “The Brillant Paula Bean” [1] but without the “taking a few months to notice” element.

1: https://thedailywtf.com/articles/The_Brillant_Paula_Bean

Spill. The. Tea.

Not OP, but FizzBuzz interview questions are famous for eliminating significant numbers of applicants.

I've learned that once you're in a large and complex corporate structure, judging your value becomes difficult. In every job I've been I've found professional slackers who truly optimize to do the minimum. They can send all the right value signals while they keep their true lack of value hidden behind a complex maze.

The only way I can think of to minimize them is to set up high barriers of entry that require on the spot proof of ability: coding tests and programming problems. Everything else can be and has been bulshitted through.

Algorithmic Coding tests and programming problems don’t tell you too much about whether they can translate business rules into code or their ability to work in complex code bases.

They may not be great at differentiating the top from the very top but they are great at establishing a minimum qualification.

If you are writing software - like most developers are - where the complexity is knowing the business process, how much good does it do to test whether the developer can reverse a binary tree on the whiteboard?

It doesn't have to emulate the work process as long as it is a good proxy. It doesn't have to do anything with what you do as work, as long as the correlation between them is strong enough. Might as well be an IQ test or logic puzzle but they have their own problems.

Many companies hire people before they decide their position. So your job tasks might wildly different.

Most companies outside of the west coast/Silicon Valley bubble hire for specific needs/specific departments.

It's important that this be a minimal qualification...the temptation is equate "can solve harder algo problems on the spot=brings more value," but that's not a great signal, and according it too much reverence overshadows other important traits (knowing which problems to solve ranking high among them)

It doesn't matter.

I've read and heard many accounts of college admission officers and hiring managers who say that among the top 30%, it is essentially random. They don't know how or even need to differentiate between the 30%, 20%, and 10%.

So what it comes down to is selecting a random differentiator that can stand up against nepotism (objective and measurable), legal scrutiny (fair), audits (easy to comply with) and so on.

Essentially everyone who answers those questions reasonably well passes. But the one who answered best gets hired because at that point we don't even have a good differentiating signal.

> People do what they want to do, and they tend to be extremely motivated as a result.

To what extends does this work? Let's say I want to work on Chrome's WebGL implementation, but I've no prior professional experience with neither C++ nor 3D graphics - would they still take me as a noob that will take a couple years to ramp up? I suspect not. So, you're probably most likely just stuck with your current niche and can only move within it - which, to be fair, is still much better than in most other companies where you're just stuck with your current project.

For domain specific roles I ought to think that the members of the current team would be more than happy to provide insight/advice/coaching to someone looking to skill up and get involved. This is typically how I've seen lateral moves done at other companies that encourage mobility. For example, moving from a primarily DBA job to devops/operations/wahetever.

The typical route would be to 20% with the team for a couple quarters to learn the ropes and demonstrate your skills, and then transfer 100% once the destination team has the headcount to absorb you. I know multiple people who have done this, although not specifically to the WebGL team.

> The people are smarter.

I’ll bite. Which other companies are like this would you claim?

Not OP, but the ones I know of are RAND, SpaceX, Illuminia, RevGen, and Tesla, in no particular order. Not saying they are good places to work, but they do seem to have more smart people than not

My last job before Google was working as a security consultant to SMEs. My experience working intimately with some 400+ such companies was that of businesses with less than 40 programmers, around one in 10 companies had one developer who could build something durable and follow "industry standard" precautions and practices. All the others had zero. At Google nearly 100% of developers are of that same quality which was exceptionally rare in industry at large.

What about Amazon?

>But it's great for the employees and it's great for innovation.

In which way is Google innovative? They have good products for sure, but I haven't seen much innovation at Google since a while. If anything the past few years have been mostly disappointing (Loon, Calico, Fiber, etc)

Surveyed business leaders ranks Google as the most innovative company in the world, innovation is not just about new products

https://www.bcg.com/en-ch/publications/2019/most-innovative-...

That's a measure of reputation, not innovation. Nobody denies that they have a reputation for innovation, but reputations are by necessity backwards-looking.

Kubernetes, which is basically supplanting how companies deploy, run, and manage software both on-prem and the cloud.

> it's hard to get people to work on something soul-consuming. But it's great for the employees and it's great for innovation.

I would argue that the best innovations tend to also be "soul-consuming". If it were easy, someone else would have innovated in that area earlier, right?

I don't think he meant soul-consuming as in difficulty, but soul-consuming as in existentially unfulfilling or disturbing to your ability to sleep at night.

There is, in my experience, plenty of appetite for hard, risky, complex, grinding, ambitious problems, and very little tolerance for boring, unimpactful or evil projects, since everyone at Google can already feed themselves and is more towards the self actualization end of the hierarchy of needs, and has no strong incentive to not roll off onto something more interesting or fulfilling.

I said soul-consuming, I meant soul-crushing (there were a lot of distractions around at the time and I was having trouble remembering the idiom).

Point being, crappy work is hard to staff, and some work is just always going to be crappy. Nobody wants to maintain a hideous collection of accumulated bad decisions workarounds that exist for historical reasons but which have no value other than allowing lazy customers to avoid upgrading their 1970s client code. At IBM we maintained it anyway and hated it. At Google that sort of thing can't keep a team together.