Ten years of experience, still failing phone screens

Just like you did, just now. I still haven't heard your explanation of how a large diameter rocket nozzle, which we are told was firing for the entire descent, with 10 psi of hot gases escaping from its large volume, failed to disturb so much as a speck of dust underneath the 'lander.' That's only the most obvious of many glaring plot holes in the script.

If you were to, say, enter 'evidence that the moon landing was fakee' into any search engine, naively thinking such evidence would be presented to you, instead you would get only page after page of laughter, ridicule, and condescension--and none of the actual evidence. Certainly you would never, ever be presented with the name of the very first book on the subject, which launched moon landing skepticism into the mainstream in the early 70s. Nowhere in the first ten pages of results is this man or his book mentioned.

The book is called We Never Went To The Moon by Bill Kaysing, who was a technical writer for the Saturn V rocket program at Rocketdyne. Wouldn't you think a man with such a background would be worth listening to? Google doesn't think so.

Another book of interest is NASA Mooned America, by Ralph Rene. This one is more technical in nature, and drives the final nails in the coffin. Google also pretends this one doesn't exist.

If you type the author and name of the book into Google followed by the keyword 'pdf' however, it will take you right to it on the first page. At least it did as of a year ago. Funny how that works.

Read those books, then come back and tell me again how sure you are.

When you find out how fake and full of lies the world really is, you're going to be pissed.

I don't know what to say to this beyond, absolutely yes this situation exists. The easiest scenario is you are on call and get paged and must solve a critical issue in as few minutes as possible.

I do believe you can do better than Google. But I don't believe you can do much better than Google at Google's scale with that many people if the goal is to hire people who can solve hard technical problems. In a small company you can have the founder or equivalent do the hiring, like early Google did, Larry Page reviewed every single candidate until they had thousands of employees. This is what they came up with after that. Also now instead of having Larry review everyone, they have the vice presidents review every hire in their org as an extra last step to ensure the hiring process doesn't turn bad or get gamed.

Note: If you don't pay like Google, or your goal isn't to solve hard technical problems like Google has great need for, then you probably shouldn't try to hire like Google. Also if you just run a single algorithm question that is easy to look up online, then you are not copying their process, since Google forbids such questions and require multiple questions. Also if you just run an automatic algorithm challenge online then you miss all the soft skills part that comes up when you talk to a person when solving the problem, so not their process either. Also a person who isn't at least decent at algorithms cannot administer an algorithm interview properly. They need to come up with an original problem, and they need to identify when the candidate has solved the problem even if the candidate did it in a way you didn't expect. Most engineers at Google can do that since they hired for that from the start. Most engineers at most companies can't. Also if you have managers make the hiring decision instead of an independent committee then you aren't copying their process. And if your executives are not constantly checking that the process is in line with expectations and doesn't bring in a lot of bad candidates then you aren't doing their process. Etc etc.

They do so many things for this to work, if you do all of that and wants the same thing as Google then it will work for you as well. But almost no companies wants to do all that work to get this working. They just say "Google does algorithm interviews, so go and ask the candidate an algorithm question and that is our process".

Also some caveats about this process and why you hear so much bad things about it:

- Managers at Google don't like it. They would prefer to hire the candidates they want, but as is it can be hard to even fill headcount you have been allocated if you aren't an attractive team, they would love to lower the bar to fill their seats. And the few people unattractive teams manage to hire often leave the team as soon as they can for better teams. I did that, I was first on a dying project and then I did well and joined a cool project working on cutting edge machine learning infrastructure. So this process isn't pushed by managers. It is the executives who want a well run organisation who wants this process. Which is why the executive review is mandatory, this process is first and foremost for their sake. And from heir perspective, hiring really smart people, put them in a poor project to test their ability and then get the best of those into the teams that matter is how you get great engineers to those important teams. There is no reason to lower the bar for poor maintenance projects even if those managers would love to do it.

For Google the most important thing is that their search and advertisement algorithms become as great as possible, and that their infrastructure costs gets optimized down as much as possible. They need the best engineers in the world to work on those things because that is where the money is for Google, quantity doesn't matter there, the rest are just hobby projects but those hobby projects can work as a way to find talent to those important projects. You can't hire experts on search and ad algorithms, because Google is the world leader in both. Google has to cultivate such talent themselves, so their process focuses on finding people who maybe could be cultivated to do those things, no matter what technical role they hire for any person could potentially pivot to the teams that generate revenue.

(Nice side effect is that every single technical role is filled by smart and ambitious people. When you talk with some guy maintaining a project you need to depend on, they are really quick to respond and answers your question or fixes your issue within minutes or hours. I never had problem with others not wanting to help or dragging things out. I'm sure it happens sometimes and maybe more in some areas than others, but I've never seen such a well run technical org anywhere else)

- Engineers at Google don't like it. It forces them to spend a ton of time interviewing, also they would prefer if they could recommend their friends to get hired, but they can't since they have to go through the process as well. The exception is the meritocracy camp, which is pretty strong at Google but not very outspoken.

- Engineers interviewing at Google of course don't like it, since it is a lot of work.

/ Sorry for writing a lot. I tend to use forums like this to structure my thoughts. This helps me better understand the pros and cons of things I know as well. Google's process is good at what it does, but not good at other things. Understanding what it is good at and what its weaknesses are is important. But now I think I have a better idea how to argue in this subject in the future. Although, once I feel I understand most things in a subject I stop arguing since I no longer learn anything. I like learning about just about every general concept, like hiring, business, programming, math, physics etc, discussions like this is what I do for fun.

I also interviewed at Microsoft (just down the street) a few years later, and got the standard interview treatment.

I know what quicksort is, and I've implemented it more than once over the years. But I could not implement it off the top of my head at the moment without doing a quick refresher on the algorithm.

I was once assigned the task of speeding up a program written by . In perusing the code I happened to notice that there were two custom bubblesorts buried in it. I replaced them both with calls to C's qsort and got a nice boost. Was a fraud? Not at all. Anybody's code can be made better. I've been found guilty of having hidden quadratic code many times.

Even if we think we see a way to solve an outage with something like this, we generally consider it inappropriate for an outage mitigation scenario, always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions.

Implementing a better or more scalable or more resilient system is important, yes, but is done after the issue is mitigated... not at gunpoint.