Part of why this has stuck around for so long is that so many people are willing to do that because it's a life-altering amount of money
As a hiring manager I view Google on someone's resume as a non-signal. If however they are the sort of person who draws attention to having worked at Google I view that as a negative signal.
The frame of reference here is important, otherwise average is pretty meaningless since we have no objective list of what an average developer consists of.
They were also not "walking in to captain" anything. They were applying for standard engineering jobs. Think of an average individual-contributor software engineer from, say, Facebook. Is a smaller company really going to hire them as Director Of Engineering (a totally different job than software engineering), just because of the company name on the resume? That sounds absurd.
I was very skeptical about this, then I worked for one. Now I get it.
All I see is that faang is a term for expert code monkey.
I'm not quite sure where the GP got stressful, but it is soul-sucking if you expect your work to be interesting, impactful, and creative, which doesn't really happen apart from a few core or research teams. There is a ton of piping and rewriting of frameworks going on all the time, even when it need not be extremely useful. This is the main reason I found it thoroughly drab—even though it is likely that the lines of code I wrote there are likely to touch many orders of magnitude more people than anything else I ever work on for the rest of my life.
I guess that's just how it goes, though.
A number of people (myself included) seek to align work and passion all in one, which is fine, except it's certainly not the only (or, indeed, even close to "best") way to live and work. I've been lucky because my passion is in a field that now actually has applications in both theory and practice, after 50-or-so years of lying in relative academic obscurity.
The point is: if you care primarily about things that aren't your work (and this is true for literally 99.9% of people in the world, and is probably much healthier than the alternative) then FAANG is phenomenal in every possible way. The perks, compensation, and freedom to do pretty much anything are incredible. Quant (which nets around the same, if not slightly more profit) certainly does not fall in this category, due to its insane hours, and most other jobs with sane hours and good work-life balance don't pay nearly (read: really even close to) as much, or aren't as secure, or have anywhere close to the perks. It really is about the best gig you can get, if you can swing it.
On the other hand, for the weird, obsessive .1% of people (e.g., me) who would be happy to work all day in their mother's basement so long as it's interesting work, then FAANG (or, at least, many teams within it) can feel almost beside the point. Which is also fine!
I guess the point is that it all depends on what you want out of work and out of, well, not-work!
My understanding is that those companies themselves also freely acknowledge that interviewing is hard. Due to the sheer volume of applicants, fast algorithms questions is the most reasonable compromise they can find at the moment. If you were in the position of the interviewer, it would also be hard for you to come up with an alternative that works for all sides involved. So instead of complaining about this reality, one needs to face up to the challenge.
It is actually a paradox: You seem to be unfree and doing something pointless when you were grinding interview questions. But after you've made it, it would suddenly be very easy for you to have a lot of freedom and security in your life with all the capital you have accumulated. In a sense it's like how college entrance exams work. It's unfortunate but again, if no better practical solution could be found at the moment, one just has to face the reality and do it. It could even be fun. Talking about "ideals" wouldn't get you anywhere in the real world.
Regarding work-life balance, perks and life quality, just as the comments who replied to you pointed out, working for big tech is most likely one of the best options you can have out there, compared to many smaller-scale companies.
The one valid thing I think you may get by not working for FAANG is complete freedom in shaping what you're working on. However this is hard anywhere unless you're the founder/executive of the company yourself. If that's what you're after and you have the safety to pursue it, sure. However, in terms of working as a common employee, there are very few possible reasons why a place could be better than big tech.
Interview is hard. A while ago there was a post by Jane Street that explicitly emphasized this point. They also require algorithms questions even though programmers there write a lot of OCaml. I guess if you were in the position of the interviewer it would also be hard for you to come up with alternatives that are much better for all sides involved.
The reason why you're expected to be fast during the interviews is that you're competing with people who are fast (either because they are smart, or because they've practiced a lot).
That being said, this type of interviews is clearly not for everyone. There are tons of skilled people who (for good reasons) don't want to play that game, and there'll always be a market for them.
I'm sure that's true once you achieve seniority. I'd wager that the first couple of years, at least, you're not solving problems, but implementing solutions designed by higher ups. You need to do this fast to be useful.
I've had candidates ask me why we do this, and my answer is that once you're in the company, transferring to another job on the same ladder is fairly trivial and requires no technical re-interviews.
I go on to describe how I've been around for 10 years and am on my 5th team. None of those transfers required any sort of technical re-check. Teams trust me when I say what my abilities are.
Sometimes they'll look at past CLs, and we certainly have a couple interviews to make sure that the fit is good, but nothing technical.
In none of my positions has it been "crank out the code, pass it off, then on to the next piece". There has always been a clear sense of ownership of my code, where I've been responsible for both the code and a steward of where and how it's used and modified.
Occasionally I've had a design review where a higher-up has said "this is why we aren't going to do it that way". I've always been given a reasonable reason (not always one I agree with, but reasonable). I've always been the one to re-write the design in these cases.
I fully expect that everybody at Google will create the designs for the problems they own, get the designs through peer review, work on implementing these designs, and verify that the solution is solved in process.
What changes with the seniority level is the scope of the designs - a junior may be expected to design their piece of code, only their module, a mid level is expected to design an entire subsystem while delegating individual modules, a senior is expected to design an entire system delegating the subsystems, etc. Of course, it's not so clear cut all the time, but the critical piece we have here is that - Everybody, at all levels, are expected to share expertise, knowledge and acumen in order to help others grow. When you put everything together it creates a nice cycle of constant growth pressure.
Absolutly I will not qualify anybody's work here as "droning", and if someone in my team would feel like that I would invite them to speak up and work together into making it better.
About the quality of people here, what has impressed me most is the uniform high level of competence and niceness. In other companies where I've worked the skills would more-or-less all over the place, but here it's uniform good. I'd rate Googlers consistently in top 20% of the teams where I've worked with before. Also everybody is so very nice, a real pleasure to be around and work together. I still haven't discovered how recruiting selects for this, but everybody constantly passes the airport test my in book.
In my experience technical interview questions are usually way harder than they need to be. I don't agree with getting rid of HackerRank style filters entirely because they save you a ton of time with candidates who just can't code at all (or candidates that think they aren't applying for a coding job). But the questions should definitely err on the easy side.
I thus gave the candidates roughly three times longer than I needed to solve the problem myself, which should pretty much account for the interview situation.
"The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
Rob Pike [1] "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."
Rob Pike [2]
[1] http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro... [2] http://talks.golang.org/2012/splash.article
It would be comical to hear, "Hire better pilots" as an alternative to building parachutes, or fly-by-wire systems.
Every one makes mistakes. This is why we have tests, linting, code review. Our choice of tools that we use (or, in this case, create) reflect our engineering needs as well. The goal is not just to hire Smart People, but to make it _hard for people to make critical errors_. At Google's scale, I can completely understand why they might feel that developing a new tool was the best way to prevent a core set of problems.
None of which is related to using a dumbed-down language.
> At Google's scale, I can completely understand why they might feel that developing a new tool was the best way to prevent a core set of problems.
There's plenty of research around software reliability and on the sources of bugs across different languages.
Research shows that verbose languages e.g. Java don't have lower bug rates or better maintainability than expressive languages like Python.
Dumbing down a language, reducing expressiveness and introducing boilerplate does not help. If anything, it removes the attention of the developers from the core aspects of an application.
A "dumbed-down" language is a tool that prevents one from being able to write certain classes of errors (e.g. some of the footguns from C).
Changing the language doesn't mean you make less mistakes, but it means that you make different kind of mistakes. I'm rather unlikely to make an error related to memory allocation in Python or Java, for example.
Making them learn go is basically training for then to be better engineers though, so that's kinda better
He's not going to get many C programmers to adopt his language if he gets on stage and announces C is a crap language and anyone who thinks their code doesn't have memory bugs just hasn't found them yet. Is this asshole saying I'm bad at my job?
On the other hand, if he says that of course you, dear reader, have never coded a bug in your life - it's other programmers who do that, and this new language will help you collaborate with those poor unfortunates? That's an easier pill to swallow.
Sounds like the exact opposite - they're specifically looking for people who can actually solve algorithmic problems, rather than just code them up.
The fact that the diamond in the wedding ring is worthless is actually a feature.
>The tests are therefore all about excluding candidates rather than identifying brilliant young mavericks with potential.
The author assumes that companies want mavericks. Maybe the FAANGs and other high tech firms still search for a few innovators, but wouldn’t they look at other networks besides the typical interview process to identify these candidates?
We are living in an age of developer commoditization, and for many large tech companies the army of assembly line programmers can churn through enough peripheral work at the right price.
Feels to me there are a lot of stereotypes and misconceptions about FAANG floating around in this thread, which I guess is not exactly surprising given the type of post this is (criticism of the "broken" interview process).
In your case it's more understandable if you wouldn't like working a conventional job, since you mentioned you're not neurotypical (though I guess you would most likely find work at most smaller software shops even more suffocating).
However, for the majority of commentators, it almost feels like some people find excuses to not even try, or have some sort of sour grape mentality/avert their eyes from the issue, if they feel themselves unlikely to pass the interview, even though they haven't spent the time required to master the algorithms questions at all. (Of course, there might also be people who simply find it quite hard to find such time, as mentioned in the article, which is understandable.)
My understanding is that those companies themselves also freely acknowledge that interviewing is hard. Due to the sheer volume of applicants, fast algorithms questions is the most reasonable compromise they can find at the moment. If you were in the position of the interviewer, it would also be hard for you to come up with an alternative that works for all sides involved. So instead of complaining about this reality, one needs to face up to the challenge.
I would conjecture that most lower-paying "programming" jobs, e.g. writing enterprise Java, are much much more "assembly line" and "soul-sucking" than jobs at top-notch tech companies, which should offer a decent amount of creativity and freedom for one as an ordinary employee.
It is actually a paradox: You seem to be unfree and doing something pointless when you were grinding interview questions. But after you've made it, it would suddenly be very easy for you to have a lot of freedom and security in your life with all the capital you have accumulated. In a sense it's like how college entrance exams work. It's unfortunate but again, if no better practical solution could be found at the moment, one just has to face the reality and do it. It could even be fun. Talking about "ideals" wouldn't get you anywhere in the real world.
The one valid thing I think you may get by not working for FAANG is complete freedom in shaping what you're working on. However this is hard anywhere unless you're the founder/executive of the company yourself. If that's what you're after and you have the safety to pursue it, sure. However, in terms of working as an ordinary employee, there are very few possible reasons why a place could be better than big tech.
Sounds like they're looking for assembly line programmers - crank out the code, pass it off, then on to the next piece of code without pause. This would be a nightmare for me. The high salaries and prestige of these companies definitely would not be worth it. I'm not neurotypical. I met an older man when younger who recognized this when he hired me so he left me alone. I worked at home and provided him programming solutions on my time schedule, which turned into millions of dollars for me and much more for him. I'm happy to let the fast programmers do the speed programming.