Neat, I just interviewed for Google for the SRE position as well. This described my experience very closely.
> I found it amazing that for each of the interviews I was given enough information in advance to actually be able to prepare myself.
I had the same thought. To me, Google seemed 100% concerned with evaluating engineering skills and they wanted to do the opposite of hitting my weak points or quizzing me on trivia. I got a pretty good amount of detail on what to expect, loads of links, book recommendations, practice exercises, and even a video SRE interview coaching session by a couple SREs (all of which I combed through, yes, I even bought two of the books). Personally, it was a great interview experience.
I also interviewed with another large software-oriented tech company, but Google put more effort into providing preparatory material.
> So the fourth interview (1:30 PM) on that day was the large systems design interview. Unfortunately, I was a blockhead on this one, then got nervous more and more and thus failed it.
It's also the area I felt the weakest in. It was the hardest to prepare for and they gave the least amount of prep material.
Admittedly I was extremely turned off by all the preparation materials. My instinct was that if I had to prepare and study for an interview, then I wouldn't be too qualified for it in my current state.
When hiring, I'm a lot less interested in whether a candidate still remembers, e.g., the details of a red-black tree, and a lot more interested in whether they can talk about them intelligently a few days after they've had a chance to re-skim the Wikipedia page.
The best interviews for Software Engineers I've been a part of, on both sides of the table, were those in which a certain level of preparation was expected.
If I ask you random language questions, that you've not prepared for, I am not selecting you for being a good developer, but by being good at remembering language minutiae, which you could always google anyway. Now, if instead I hand you 2000 lines of code 2 days in advance, and tell you that we'll be working on them during the interview, I get a much better approximation of what you can and can't do in a real life scenario. Can you become very familiar with a tiny codebase quickly? Can you really analyze it critically, and tell me where it sucks? When asked to fix bugs, or make code changes, can you make the changes actually fit into the existing structure, or are you going to want to rewrite the world?
If you'd get a very different result in an interview if I gave you the questions I was going to ask an hour in advance, then I am not testing work skills at all. You don't hire a juggler by seeing if he is good at playing basketball, you watch him juggle.
I don't understand the prep part. If you have to do a lot of prep for the interview doesn't that mean your current skills aren't a good fit? And if they don't want to test your skills but your ability to solve problems wouldn't they want to test something you're already skilled at?
The interviews cover a lot of potential material in depth and I think the perspective is that not everyone works with all of those topics frequently and may need a refresher. Since Google knows what skills they want the interviewees to have, they share that information so the interviewee can round themselves out so that Google can identify their potential fairly. Like I said before, my experience was that Google tried very hard to avoid turning people away because they accidentally hit a weak spot or quizzed them on some bit of trivia.
For me, the preparation was primarily:
* honing the skills I did have to make sure I was comfortable using them in a tense situation
* refreshing and re-honing some things I hadn't seen in a while (some since college)
* filling in some gaps of knowledge (so I could connect the dots in an in-depth explanation better)
* preparing my thought process for the types of questions I'd have
The last one is subtle but important. If the interviewee has a good idea of what is expected of them, they can converge on a good path quickly and avoid going down rabbit holes or wasting 15 minutes trying to get on the same page as the interviewer.
As a side point:
> doesn't that mean your current skills aren't a good fit
Don't they really care about your skills at the time of being hired (which they approximate by measuring them at the time of the interview)?
I had the same question. I spoke to two Google SWEs about it, and also went through their interview process.
I concluded there's a number of factors at play:
1. Google views software engineering skills as fungible. If you can learn domain X, you can equally well learn domain Y. Hire smart people, and put them on something they find interesting, and you'll get high quality work out of them. Computer science / problem solving then becomes a sort of proxy for whatever skills are ultimately necessary. If you can learn that, you can learn anything.
2. Google wants to quantifiably improve its interview process, which requires that it be standardized. Tailoring the interview to the candidate too closely makes it harder to compare interviews across candidates. Computer science and problem solving are reasonable baseline skills for a SWE.
3. Having a famously difficult interview helps Google cultivate a reputation for exclusivity, which in turn attracts candidates. Same as why universities like to show off low acceptance rates.
But also some less charitable factors (which are by no means limited to Google):
1. NIH syndrome. Skills acquired outside Google are viewed as less relevant precisely because they were acquired outside Google.
2. Ego. I want to pretend my job is more about sophisticated algorithms and problem solving than tracking down null pointer exceptions.
3. Ageism. Whether chosen consciously or not, structuring the interview around topics taught in school / programming competitions, instead of on the job, slants the process towards recent graduates. Google has one of the youngest workforces among established tech companies, outside of Facebook.
When I've asked Google engineers about it, they've admitted that their interview process is imperfect, but also think it's the least bad approach known. At a minimum they deserve credit for working to improve it, instead of the haphazard approach employed at most companies.
> 1. Google views software engineering skills as fungible. If you can learn domain X, you can equally well learn domain Y. Hire smart people, and put them on something they find interesting, and you'll get high quality work out of them. Computer science / problem solving then becomes a sort of proxy for whatever skills are ultimately necessary. If you can learn that, you can learn anything.
I get the impression from your post that you view this as a positive attribute. I actually think it is a negative. I feel that, like other engineering disciplines, software engineering is so broad (and getting broader every year) that skills are not truly fungible and that a certain level engineers must specialize. The result is that companies like Google either test for a breadth that fewer and fewer engineers can actually achieve, or they trick themselves into thinking their evaluation covers everything when it does not. It might (a big might) work when you are only a couple years removed from your undergraduate degree, but its a lousy way to hire experienced people.
One of my valuable skills according to a previous employer was my "google fu" - or my ability to condense any problem into something searchable and come out with a working solution.
This covered everything from design patterns to failing SSD's to static init order problems in C++ to arm assembly instructions...
Sadly every interview I've been in usually involves being a human compiler and key/value store for algorithms rather than being a human problem solver.
Every interview I do is the opposite of that. I basically do a screen share/stare over the shoulder as I try to get them to implement toy features programs. I see how they solve things and their thought processes. Stack overflow is often involved. It's about the closest thing I can think of testing for a real work environment.
Other co-workers do the algorithms KVS stuff and classic concurrency quizzing although. We need both.
Now I'm trying to think how I can interview people for coding design decisions & wisdom. Like religiously following the Don't Repeat Yourself principle or other things out of the pragmatic programmer. You can be an algorithm KVS star and still do stupid shit like that. All I have is hints, like 'sorry for this copy paste but I only have 10 minutes left, normally i wouldn't do this'.
I'm really starting to understand the damage bad coders can cause to a code base attitude that google has. It can create a 5 people shoveling more shit than you can shovel out at a time situation that you really want to avoid.
Anything you can study up for in a couple of weeks is also something you can learn on the job. What's the point of throwing a perfectly good candidate into an unfamiliar situation without any prep? When you actually get the job, there are plenty of people around to help you learn new skills.
On the flipside, Google probably wants its employees to be motivated to self-learn/develop. It also allows the candidates to have a certain baseline of knowledge before having to pick up Google-specific stuff that they'll probably be flooded with.
Google has a strong reputation for paying well & being a desirable company to work for in the minds of many, so they can afford to do this as a part of their process.
If you were casting actors for a play, would you rather hit each candidate with a surprise audition five minutes after they got out of bed, or give them time to review the lines and stretch their vocal cords?
That's not a fair comparison at all. Interviewees know well in advance of when the interview will happen. A more apt comparison would be telling an actor what script to use for the audition vs giving them a script they've never seen before at the time of auditioning. This still isn't a fair comparison though because they're testing acting talent, not the specific script. A good actor can learn the script.
I imagine they (Google) doesn't consider this information private so here's the bulk of an email I got listing prep material and topics: http://pastebin.com/iXGzfkBL
Yep, I got a very similar e-mail before the on-site. There was some more in some e-mails before the phone interviews, like links to man pages, some (public on YouTube) Google videos, and some sample coding problems.
FWIW, I bought "Programming Pearls (2nd Edition)" and "Advanced Programming in the UNIX Environment (3rd edition)". "Programming Pearls" was definitely a good choice.
My problem with APUE is that it includes so much detail about platforms I'm not likely to be exposed to. It's probably a great reference for that stuff (it's almost a rosetta stone for unix programming), but it could probably be half as long without the "extraneous" stuff.
There is a now classic Steve Yegge blog post that gives a recommendations and advice (a lot of Google recruiters actually point candidates towards it to prepare). Although it's over six years old now it's still pretty much on point.
I just started at Google two weeks ago (as a SWE, not SRE, though), and I found Cracking the Coding Interview to be the most helpful book for preparing for interviews in general. I also used Programming Interviews Exposed, which is comparable, but CtCI has a little more content.
yes also would be interested in this. Also even a vague example of what one of the questions might look like (not asking for an exact interview question)
I've found that this website contains a lot of onsite-like coding questions and is generally really good for practicing problem solving (it's basically Project Euler but for programmers): oj.leetcode.com/problems/
Care to share the book recommendations? I'm curious because I've been contacted by Google recruiters before, but have never done well enough to be hired. I'd like to get to the point where I was SRE material, even if I were to be hired by another company and not Google. I've never seen any reading material suggestions or videos.
> I found it amazing that for each of the interviews I was given enough information in advance to actually be able to prepare myself.
I had the same thought. To me, Google seemed 100% concerned with evaluating engineering skills and they wanted to do the opposite of hitting my weak points or quizzing me on trivia. I got a pretty good amount of detail on what to expect, loads of links, book recommendations, practice exercises, and even a video SRE interview coaching session by a couple SREs (all of which I combed through, yes, I even bought two of the books). Personally, it was a great interview experience.
I also interviewed with another large software-oriented tech company, but Google put more effort into providing preparatory material.
> So the fourth interview (1:30 PM) on that day was the large systems design interview. Unfortunately, I was a blockhead on this one, then got nervous more and more and thus failed it.
It's also the area I felt the weakest in. It was the hardest to prepare for and they gave the least amount of prep material.
(Disclaimer: I start with them in 3 weeks.)