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.

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.

Certainly there are other ways to verify someone can code: code samples, talking through high level language concepts, reviewing existing code, etc.

What people should be focusing on is this - 1) Do you understand enough systems architecture / code techniques to succeed at this particular company? This can be done via mostly talking. 2) Do you have experience that will help us with our company-specific problems? Give them an actual problem you regularly deal with, and get them to attack it.

it's impossible that they don't know about it. the more i think about it, it's that they're either lazy or want to select for age but obviously can't do that in an overt way, so they pick a tool that nobody with a family has time to grind (i.e. 'old' people)

Vast experience in compilers, embedded systems, functional languages, graphics, dev ops, or cloud technologies will be of no use. (Perhaps it will be later, if you get to a systems arch interview step.)

For example, the only time I ever encountered red-black trees was in the context of prepping for software interviews.

Mine had data structures and software engineering as CE-specific requirements (along with a dash of microarchitecture and HDL/FPGA stuff), the CS algorithms course was an elective that obviously gave priority to CS majors.

Beyond that, we had a department head that really only cared about shoving as many EEs as possible into the PG&E hiring pipeline.

Here's a radical idea (read to the end before you object). The inspiration is a blend of how open source projects recruit developers, and how the 20% Google side-projects used to work.

I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.

Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you. How can we make this work: legal framework. California, if you are listening, pass a safe-harbor law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so (so I worked for company B for a few days or weeks, not months). Would that work?

This is a key insight that people need to understand.

In a 20 year career I've only ever been on the market once (in 2017), and I saw it as a huge opportunity to join the best possible company. I did over a dozen on-sites, and every single one of them was 5 hours plus, sometimes multiple, w/ take homes or phone screens additionally. The results were shockingly random in terms of many different factors ranging from familiarity and fluency with the class of problem, to the style of the interviewer, to the order of the interviews and how exhausted I was by the end. The outcomes in terms of offer/no-offer also bore little relation to my perception of how the interview went.

I think this doesn't sit well with people (especially technical people) because they want things objective and fair. However standardizing process and addressing biases only gets you so far because at the end of the day interviewers and candidates are all unique. Success in a role is highly dependent on context that one operates in.

Honestly I don't think the hand-wringing helps anyone. At the end of the day you have to just play the game. Hopefully companies continue to employee a variety of different interview techniques, because they all have different biases and so the best thing is just to ensure a diversity of techniques so everyone can find their place.

I'm a while out of school and one interview I went on had a requirement for a live coding session. The ask was to implement red/black trees from scratch despite the fact that they have an Angular app with MySQL on the backend. I took this as a blessing. I don't want to work at a place where they think this is a good way to hire people.

To make an analogy, I'm always perplexed at how you're asked to build an EPR on the spot and then all you do is general electricity mundane work. I've seen a lot of EPR builder beeing incapable of simple wiring ...

NB: First result of an "EPR electricity" search.

But you don't need to go that very deep. What they ask is very specific and (unfortunately) you're better off going through 10-20 typical interview questions and their solutions.

Typical questions are "how would you design Google News/Twitter/...". There are many resources available, all of this is discussed on leetcode or interview preparation sites.

It's not hard, but I'd recommend to prepare for this well-before your interviews.

I think that's the standard recommendation

Thank you very much for listing this. I wonder how life is for older candidates in these jobs.

Most of the interviewers were in their 20/30s and so is everybody on their "career" web pages and presentation documents. However, in the team I'll join, at least two people are about my age or older.

What I can tell is that never in the recruiting process did I feel discriminated against. Once you're in the loop, their main concern seems to be how well you perform in the interviews. I feel I was at a slight disadvantage compared to to my younger self in term of thinking speed for the algorithmic questions but this can be compensated by a better preparation.

EDIT: not sure why you're down-voted. Ageism is a thing and a legitimate source of concern.

There’s some folks here who REALLY don’t like talking about true ways our industry can fail and in some cases has failed at being decent and fair and ethical to people of protected classes, or just in general.

Thanks for your reply! For full context, I am older too, that's why I asked.

Oh I grokked it ;) but I felt very it needed a very fine and hyper-specific point to it because I'm older too, I also happen to be a racial minority, and it's a frustrating and sore point of mine-the way these topics sometimes (though in my honest opinion: far too often) get blunted and watered down so that whomever can avoid the uncomfortable sensation of staring a reality they don't suffer from, but might (operative word: might) be an unwitting participant of in the maw.

Let it be said now that your eyes are on this line, dear readers: that's not me suggesting or intimating that the person I replied to above is doing this. They're not. But it is a trend that some would be more than happy to pretend doesn't exist because they haven't had a reason to tune their cognitive receivers into the broadcast frequency people like me are sensitive to and have been bombarded with for far longer, with far worse outcomes.

And I will speak out about it.

Every time.

Downvotes be damned.

I guess the pay is phenomenal but I have a hard time imagining that this kind of algorithmic trivia approach makes any sense at all for hiring into senior roles. Especially if someone was trying to move laterally between FAANGs.

I've long been opposed to the Leetcode battery interview processes, to the point that I started asking FAANG recruiters that several years ago, and saying that was a showstopper for me, like a signal for how they treated people. Though I otherwise wanted to work at a couple of them.

After consulting levels.fyi, however, I've revised my opinion: if an employer is willing to pay a higher-level software engineer 2x the total comp they'd make most other places... whatever interview process they want suddenly becomes a rich and honored cultural tradition, to be treasured, and approached with the utmost reverence and humility. :)

That said, for people who've frittered away their discretionary time on things like open source, hobbies, family, etc., rather than drilling for FAANG interviews, the well-known "test prep" commitment for Leetcode-oriented companies is a barrier to even applying there.

Salary aside - this is the truth right here. I interviewed at a few FAANGs and I didn't have what Id call a good experience. Neither resulted in an offer. To even prepare for them was a monumental time investment. I tried it and now I can have an informed opinion on the subject. Id rather have a life than drill for random interview questions.

Side note: I have yet to personally hear or read anything about why its so great to work at one of these places where someone DOES NOT mention the money. Frankly, were it not for the money Id have never even considered interviewing at these places at all. I have come to the opinion that if it's just money, there are other more tangible ways to invest my time that will result in money. Drilling For Interviews as a money accumulation seems to me a bit like heading to the casino on the 28th of the month because you're short a few bucks for rent.

The big G, for example, already seemed like the place to go, as soon as they launched the early site (the company was obviously smarter than most of what was going on), and there was also the "don't be evil" that resonated with a lot of the prevailing sentiment among the pre-Web Internet-savvy techies. Though I suppose there might've already been a money factor from the start (it seemed like most people were crunching hard at work, but also prone to job-hopping for the hottest IPO lottery ticket at the moment), but it wasn't as clear as today.

But I understand that people who invested a lot of time (and sometimes money) on their preparation feel extremely bitter if it didn't pay out in the end. It's also unfair that some candidates (especially some who have a family or not much time off) simply may not have the time for this.

So true. It's not enough to write some approach that's better than brute force. We need to write the best possible method. And sometimes interviewers do not encourage methods that are not on their mind.

Just sucks!!