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