Comment by pavas | Hacker News Reader

Comment by pavas | Hacker News Reader

Parent Full thread

The interview process for FAANG companies is primarily focused on preventing false positives because of the damage that can be done by individuals when working at scale. Unless you have a really large sample size I wouldn't take any of that personally because for each interview, luck is involved.

Furthermore, the process is partly about how good you are at being able to learn, and partly about how well you are able to keep yourself motivated to grind something out, or a combination of the two. Given enough time, FAANG interviews are 100% something you can study for, and furthermore, it is expected that you spend the time to study for them as that is also a signal of something in itself.

On the job, you'll either have to be smart enough to pick stuff up quickly or spend the time to grind out the work (working overtime, etc). You also can't fuck things up too much because the fallout can be really expensive, so it helps to be able to do things right the first time. I think what is generally tested in the interview correlates with these requirements, and prevents false positives (and probably lots of false negatives too but you can just study more and try again at that point).

I would guess, with some evidence from experience, that all FAANG companies have sufficiently bureaucratic process, checks, and balances, to largely mitigate the risk of a disaster caused by a lone wolf screwing something up. Multiple cross-functional sign-offs whenever you deploy something to production, mandatory code reviews, gatekeeping access to push changes for junior folks, etc. This has got to be a mostly solved problem for companies of that size.

I'm not denying they are primarily focused on preventing false positives, but not for the reason you mentioned.

Yeah there are definitely other reasons but this is one of the biggest in my opinion.

There's always a tradeoff between security/bureaucracy and speed in delivery so as to remain competitive. This does matter even at large scale.

I would agree that if one were purposefully trying to cause as much damage as possible, that impact would be contained by these processes.

But one can still make mistakes or be a drain on the team's energy and focus which increases the chance of mistakes team-wide. At scale, even minor mistakes are costly, not just in terms of direct impact but in terms of the opportunity-cost of developer effort that could be better spent elsewhere.

Of course, my direct knowledge has sample size of n=1 here so it likely does not apply uniformly across all large companies.

I would love to hear contrasting opinions on this topic. I've spent a lot of time thinking about what would help developer teams increase their productivity w/ regards to adding value.

Reply on news.ycombinator.com