People often ask me for advice about working at Google; and now that I don't work at Google I get asked twice as often.

You have been given this URL if you wrote to me directly asking about Google.

Here are my standard answers:

Should I work at Google?

Yes. It's a great place to work. Even though I no longer work there, I think it is a great company with a long future. They treat their employees well and the work environment is excellent.

What are the roles of a sysadmin at Google?

SRE's work on services.... either live production services or internal services.

Corp Engineers do customer support and other internal projects.

Data Center Technician... literally run around replacing hard disks all day.

I was an SRE. I don't know anything about the hiring process for Corp Engineers... except that if you are a friend of mine and are asking me about working at Google, you probably don't want that job. It is mostly technical support. Most people I know don't want to do that kind of work. The people that do that at Google are the best and they get all my love and respect but, again, people that ask me directly about interviewing at Google generally don't want that kind of work.

If you think getting hired as a Corp Engineer is a good way to "get in" so you can move into SRE, think again. You'll have to interview from scratch to transfer.

Can I work at Google as an SRE?

Probably not. Let me set expectations: Their system administration positions are very difficult to get. Basically they've automated everything to the point where there is very little traditional system administration that needs to be done. Instead, they need software developers that have an understanding of system administration.

There are 2 skills they look for: operations and software engineering. Google SREs need to be pretty good at both, and a strong candidate is "awesome" at one or the other. If 0 is bad and 1 is awesome, then Google SREs are at least (0.5, 0.5) to be hired. Most are (0.5, 1) or (1, 0.5).

And, if you didn't understand the (x, y) notation in the above paragraph without needing it explained to you, you shouldn't apply to work at Google.

How should I prepare for a Google SRE interview?

Get a 4-year degree in software engineering with a minor is system administration.

Or...

Read the Steven's book on unix system programming, and Kirk's book on FreeBSD internals. They don't use FreeBSD at Google, but the info in that book is a better description of how Unix works (in general) than the Linux books I've found.

"But I'm an awesome sysadmin! I know everything about Debian AND Redhat!" Good job. Sadly, Google has abstracted away all that kind of stuff into their own package management (Containers) and execution system (Borg... its like a big version of Kubernetes). Therefore, they interview you based on what you know, but they're looking for the skills that show you can learn their internal systems well.

What they really want to know is:

• Do you know the "under the hood" bits and bytes of what you work with, or are you just happy knowing the external veneer that beginners know? Superficial knowledge is good for most people, because they can call the vendor when things get difficult. At Google, you need to know the guts of how things work because there is no vendor to call.
• Do you test things first or do you just throw them into production and pray? Yes, you can learn a "test first" way of doing things, but Google would like to know that you already have that habit.
• If you put it into production, do you monitor it? It isn't "done" when you put it into production. It is "done" when it is running, and monitored, and documented, and capacity planning is worked out, etc. etc.

If I have an interview, what should I do?

Relax.

The first interview is the "phone screen". It is with the recruiter who is non-technical. They've been trained to ask the question and what to listen for as an answer. This is really just to get rid of people that are faking it... and you'd be surprised to learn that 80% of the candidates drop out at this point. (Yes, there are people that don't know what an IP address is, or how many bits are in a byte. No, those aren't the questions, but I'm not too far off.)

Next you'll speak to an engineer for the "technical interview". You'll think this is "round 2" but internally they consider this "round 1" because the "phone screen" is really just a simple filter.

In the technical interview they'll ask you a question, then keep asking for more details until you say "I don't know". Don't worry. They just want to find out how far you can go with technical details. Some people say "I don't know" after 1 "can you go deeper" and others go 3 or 100 levels deep. However each line of questions will eventually end with you saying "I don't know". Therefore, don't freak out that every new question eventually makes you say "I don't know". They may be looking for someone that can go minimally deep, but you went very deep. You won't know.

A lot of people feel like this means they fail the interview because they said "I don't know" so often. Relax. They have positions at many levels and you are being interviewed for all of them. They want to see where you fit in. Maybe you are a level 3 or a level 5. They are probably hiring both. (though I think they no longer hire level 1s or 2s.)

When you get to the "I don't know" part... just say, "I don't know. May I guess?" Then explain the logic behind your guesses. If they know you are guessing, they'll judge you on your logic, not on the details. You can be wrong on nearly every guess but if your logic is sound, they'll hire you.

Oh, and for every question, always repeat the question back to them to make sure you understand it, and ask "how much detail would you like?" 9 times out of 10 people go off into detail that the interviewer doesn't need and that wastes time. Or worse, they start answering the question without actually understanding it. Force yourself to always ask at least one clarifying question. In fact, practice this for the week prior to the interview: never answer a question without first asking a clarifying question. Develop that habit. If someone asks you, "do you want to go to lunch?" ask "today?" If someone asks you to pass the salt, ask them, "this salt? to you?" It is silly, but it develops the habit. During the interview if you can't think of a clarifying question ask one of these: How big is the dataset? Do you want a first draft guess or a detailed analysis?

Speaking of which, any time they ask you to design something or write code try to understand the scope. The best candidates say out loud: "May I give you a basic design and then iterate?" That way you can solve the easy case, evaluate that, then expand it to the more difficult cases.

They will ask you to write code. Ask, "are you evaluating the algorithm or do you want every semicolon and comma to be correct?" Usually they'll ignore minor syntax issues if you are at the whiteboard. If you can't remember the order of parameters to lseek(), tell them. They'll give you a pass on anything that could be found in the manpage. (by the way.... lseek() can be relative to the start of the file, the end of the file, or the current file position.)

Will I get hired?

I hope you do and I wish you luck.