Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Something that also plays a big factor in the general over qualification of FAANG employees is that mistakes can be very very costly. It’s worth paying one engineer that gets things right 99.99% of the time twice the salary of engineer that gets things right only 99.9% of the time.


From what I recall of the training I received from a somewhat well-known Chief Quality Officer, you don't get things right more often by getting better people, you get things right more often by making better processes for people to follow (the latter of which isn't as directly tied to better people as you may think).

Frankly, I don't get the hype. I've interviewed FAANG engineers and have given a thumbs down almost as often as I did for engineers from other companies.


Agree on the process points.

Re: the hype .. what I would say is, as an employee of a FAANG, is that I work with really smart people. Some of the smartest and most competent people I've ever worked with. Most much smarter than myself.

But after 9 years, I'm not convinced that their intelligence always yields results that exceed that of other companies I've worked at. In some ways, yes, but in other ways no. So, I dunno.


I think it's because building software is a team endeavor. Just because individuals are smart doesn't mean that the end result will be great.


Yes, the McDonald’s philosophy.

Having clearly articulated processes certainly help consistency.


The problem with consistency is that if you're not already doing the right thing, you'll never do the right thing. Not even by accident.


I disagree.

Even if you are doing the wrong thing consistently, one has a much greater chance of knowing what parameters can be tweaked to alter the outcome.

Consistency is easier to monitor/log.

It is easier to experiment.

Without consistency, it is much more difficult to know which of your decisions changed the outcome, or was it just good or bad luck.

Toyota and McDonald’s are successfully companies, but they are not perfect.

Kaizen and consistency are not mutually exclusive.


Possible, and that does sound nice.

But in my experience striving for consistency means that before improving something you have to go and change everywhere that pattern appears in 400 different code bases going back 20 years (and all of the documentation across however many platforms). As a result nobody ever improves things.

As with all things YMMV.


This is something that gets parroted A LOT, and has been for at least 20 years now.

I'm not saying that you're wrong, but I'd really, really like to see some actual numbers on this.

My biggest gripe with this theory, is that it assumed all responsibility and decision-making on a single worker. In every other industry I've worked, where employees have the access to some extremely costly "kill switch", where you can basically bring down the whole system, it's always - ALWAYS something that needs to go through multiple people.

That also goes for more fundamental roles, like design and implementation. These things go through multiple people, reviews, and later audits.

I'd be amazed if internal guidelines and regulations at FAANG behemoths allow potential multi-million decisions to rest on single employees.


Is the "costliness" because of the scale the systems operate at?

It's not a knock on the companies or employees, but my initial reaction was that embedded code in safety critical systems like what operates infrastructure, cars, airplanes, etc. would be less forgiving in terms of mistakes




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: