Live data from Hacker News

'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

business-standard.com

271–280 of 1001 posts

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#271

Maybe it’s not the employees fault, but the management who hired them… or maybe it’s the fact that it takes forever to get anything done at FAANG nowadays. Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders.. but a great way of identifying people who can hack a process to secure maximal reward. Look, if I can ‘crack the coding intervi…

>Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders

The interview process at FAANGs isn't designed to hire the "best" people. It's designed to hire people who are "good enough" in a consistent manner. Any form of standardized interview can be gamed. More personalized interviews can be better in theory, but they also open the door to nepotism and discrimination.

Admittedly, I'm biased because I'm unusually good at Leetcode and a rather lousy in terms of development velocity. With that disclaimer out of the way, I think the last thing that FAANGs need are more "high performing builders". In my experience, a lot of them tend to create a lot of useless passion projects that work their way into being dependencies and end up causing more harm than good. I may be a rest'n'vester, but at least I make sure the work I get done creates positive value for the company.

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#272
post #165

By the end of my employment at Google I was not working very hard. Probably a few hours a day, mostly doing whatever I felt like doing. My managers consistently gave me "meets expectations" regardless of how much I achieved or how hard I worked. However, any time there was an emergency related to my function, I had everything required to jump in, fix serious problems, and then get out of the way during the cleanup th…

That's how I think of it. You pay firemen for their ability to solve a problem quickly and efficiently, and for being able to execute when called upon.

Giant companies making money hand over fist pay a lot of "don't fuck this up" salaries. The primary goal for everyone is to keep the money printer running smoothly; everything else is secondary.

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#273
post #245

As a consultant, I come around a bit. I have seen many companies with very poor productivity, and in zero of those cases was it laziness of the employees. In fact they usually would have loved to be more productive. Nobody wants to spend their life being dead weight. But as companies grow they install more and more rules and regulations that end up making sure nothing ever gets done. It is not unusual to meet "develo…

Not getting rid of "legacy" stuff that doesn't work is a, IMHO, a version of throwing good moneybafter bad money. Instead of acknowledging that the unusable code, or whatever, was a crucial part of understanding the problem, and throw it out once the problem was understood, people tend to build upon those not fit for purpose things...

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#275
post #265

Earlier quoted context omitted.

What are test engineer roles like at Google? I’ve basically only spent my time in startups on critical systems (defense, finance) so have no idea what it’d be like at a larger company or team.

This was a long time ago and it was a "bespoke" position created by the SRE team. I set up a continuous build and then fixed bugs until it went green. Test engineers at Google at the time (~2008) were expected to build test infrastructure, rather than writing unit tests (SWEs were expected to write unit tests and integration tests), or to build complex system tests.

Yeah that sounds pretty familiar to my experience! Right now I'm in an infra team and work on the CI pipelines, testing frameworks for devs, testing infra, etc... So more time dealing with docker/k8s than a unit testing framework that's for sure!

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#276
post #137

Earlier quoted context omitted.

How would they get that comparable info from other companies? Do the CEOs all have a secret slack channel were Satya is bragging that one MS dev equals 3 googles programmers?

All you have to do is take the company's rev/profit and divide it by the number of employees (factoring in how much you pay an employee) So yeah if MSFT can make 3 billion dollars with 1000 engineers, and Google makes 1 billion dollars with 1000 engineers, then 1 MSFT eng is worth 3 of Googles (simplified - obv business involves sales, marketing, etc)

Is that really an accurate way of measuring anyways? Company A may just have a more complex product and need more developers. Doesn't mean Company A should just remove developers since Company B doesn't need that amount for their unrelated product.

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#277
There's a lot of pointing fingers here. At the risk of sounding crass, any company with more than 1000 employees (pick a number) has high performers and low performers. Yes, culture, management, and process all basically move the sides of the bell curve, but nothing "fixes" human nature and organizational inefficiencies as companies grow.

This is why companies rate and rank employees and low performers find their way to the door and/or go through [bi]annual RIF processes to clean up the org. It's the natural growth process.

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#278

Glad these guys seem to finally be noticing. I was a software engineering manager at a lean, high-margin, profitable start-up based in the NYC area starting in the late 2000s. We were acquired in 2014 by a very typical (for the time) SV-based competitor that had raised hundreds of millions in an IPO a few years earlier. Our acquirers had yet to see a single quarter of profit, of course. I and my team had so many good…

> I remember the engineers on my team from HQ explaining to me that my proposed stand-up meeting schedule wouldn't work beacuse their intramural basketball league scheduled their games for that time. Meanwhile, in our low-perqs atmosphere in NY, distractions were limited and productivity was high. We also all made money. Your standup meeting could've been an email. Their immovable basketball game (quality of life) is…

This seems crazy to me, but I don't work in FAANG. A basketball game (I'm assuming recurring) during work hours? Quality of life from inside work? Are you all at campus for most of your day (ie, longer than 8h?)

To me, quality of life is working hard and smart during the 8h, and keeping the rest of the day for you and your family. Quality of life comes from outside work, and the company respects and encourages that boundary. Of course we still do team building activities, but these are occastional off sites. Or optional after work things (drinks, workouts, indoor football etc)

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#279
post #245

As a consultant, I come around a bit. I have seen many companies with very poor productivity, and in zero of those cases was it laziness of the employees. In fact they usually would have loved to be more productive. Nobody wants to spend their life being dead weight. But as companies grow they install more and more rules and regulations that end up making sure nothing ever gets done. It is not unusual to meet "develo…

I thought the point of iterating early is that sometimes writing code is the best way to gain understanding of the problem (depending on the kind of problem). You're supposed to throw that stuff away... it's iteration...

Re: 'Too many employees, but few work': Pichai, Zuckerberg sound the alarm

#280

Earlier quoted context omitted.

> Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders.. but a great way of identifying people who can hack a process to secure maximal reward. If anything, that might be the best way to identify someone that fits in a large corp like Google. Someone that doesn't mind going thru the drudge of studying esoteric CS problems probably will…

I'm not sure I understand the comparison. CS interview problems are interesting, well-constrained math riddles with endless variety. As far as I can tell, they're nearly the opposite of menial drudgery. I don't think they're great for interviewing, on account of how they don't resemble what programmers actually do, but I do think they're a heck of a lot more fun than menial labor, especially when job offers aren't ri…

You might find them interesting, but I guarantee you many people do not. Many find them... well, something like programming trivia.

Some people love going to trivia night! Get some friends, get quizzed on some stuff, feel smart.

Lots of people are not interested.

Post reply on HN