[driverdan]

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?

[B-Con]

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)?

[millstone]

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.

[vonmoltke]

> 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.

[nanidin]

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.

[mahyarm]

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.

[enneff]

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.

[Bahamut]

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.

[raldi]

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?

[driverdan]

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.

[aiiane]

Got it in one.