3 ms·

They've actually said as much. They understand that their process generates false negatives but they don't want any "crud."

sabat 16y ago
Lots of grilling on obscure UNIX trivia and data structures/algorithms but nothing on the broader picture They understand that their process generates false negatives but they don't want any "crud." But quizzing on random trivia is irrelevant to the process of eliminating crud. It's quite likely that a cruddy performer will be able to rattle off all known sorting algorithms or all the option flags for GNU grep -- that has absolutely no bearing on true intelligence or any of the other qualities that Google professes to be interested in. Having some insider's knowledge of Google: the process does not appear to be working. There is a lot of crud in there now, and the crud only seems intent on hiring more crud. Lots of power struggles and posturing; less and less innovative thinking.
- X-Istence 16y ago
  Ah, but this is not your normal unix trivia, the questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem and other questions along those lines. This is not just flags to give to a process to make it do something, this is system internals. When I mentioned that I knew FreeBSD fairly well I was asked questions specifically about UFS and the likes. I never did get asked about flags to grep and other UNIX tools.
  - sabat 16y ago
    the questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem Precisely what I mean by unix trivia. What's the difference between /dev/mem and /dev/kmem? I think it's memory vs kernel reserved memory, but in my 16 years as a unix admin I have never once needed to know that. If I did, I'd go look it up. That is why I consider those questions trivial: they're not fundamental, although you can make them sound like they must be.
smokinn 16y ago
Exactly. They've also said that their high false negative rate is why they clear out their records every couple of years. If you got rejected a couple years ago you can apply again and they won't be looking at your previous attempt's performance.
- illumin8 16y ago
  This is the first time I've heard of this. I interviewed back in 2007 for SRE, and again in 2010 for SRE. I was told "we'll keep your resume in our database and let you know if anything comes up." It kind of goes against Google's entire corporate culture to ever delete information like this. Sometimes I wondered if their interview process isn't designed more as a data mining process to find out what interesting things technology leaders are working on. What Google should do if they want to hire really good candidates is to go with a contract to hire approach. Find good candidates, do one phone interview and a second in-person interview in the space of a few days (not 4 or 5, stretched out over months). If they pass your initial 2 interviews, hire them as a 6 month contractor. See how much they accomplish in 6 months. If they are contributing and integrating effectively, hire them full time. If not, just wish them the best and don't renew their contract. This is the way it works in most effective large companies. The cream that rises to the top gets offered a full time job within a 6 month to 2 year timeframe. My current job is like that. I've worked there for 4 years and started as a contractor. It became so expensive to pay my hourly rate that they were begging me to become full time after a while. I was doing a valuable job for them and was very effective at it, so I got the full time offer.
- LiveTheDream 16y ago
  Not to mention that in a couple years you can become a much stronger hire anyway, especially early in your career going from 0 experience to 2 years. Experience = Time * Density [1] [1] http://stevehanov.ca/blog/index.php?id=105 http://stevehanov.ca/blog/index.php?id=105

sabat 16y ago

Lots of grilling on obscure UNIX trivia and data structures/algorithms but nothing on the broader picture They understand that their process generates false negatives but they don't want any "crud." But quizzing on random trivia is irrelevant to the process of eliminating crud. It's quite likely that a cruddy performer will be able to rattle off all known sorting algorithms or all the option flags for GNU grep -- that has absolutely no bearing on true intelligence or any of the other qualities that Google professes to be interested in. Having some insider's knowledge of Google: the process does not appear to be working. There is a lot of crud in there now, and the crud only seems intent on hiring more crud. Lots of power struggles and posturing; less and less innovative thinking.

X-Istence 16y ago
Ah, but this is not your normal unix trivia, the questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem and other questions along those lines. This is not just flags to give to a process to make it do something, this is system internals. When I mentioned that I knew FreeBSD fairly well I was asked questions specifically about UFS and the likes. I never did get asked about flags to grep and other UNIX tools.
- sabat 16y ago
  the questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem Precisely what I mean by unix trivia. What's the difference between /dev/mem and /dev/kmem? I think it's memory vs kernel reserved memory, but in my 16 years as a unix admin I have never once needed to know that. If I did, I'd go look it up. That is why I consider those questions trivial: they're not fundamental, although you can make them sound like they must be.

smokinn 16y ago

Exactly. They've also said that their high false negative rate is why they clear out their records every couple of years. If you got rejected a couple years ago you can apply again and they won't be looking at your previous attempt's performance.

illumin8 16y ago
This is the first time I've heard of this. I interviewed back in 2007 for SRE, and again in 2010 for SRE. I was told "we'll keep your resume in our database and let you know if anything comes up." It kind of goes against Google's entire corporate culture to ever delete information like this. Sometimes I wondered if their interview process isn't designed more as a data mining process to find out what interesting things technology leaders are working on. What Google should do if they want to hire really good candidates is to go with a contract to hire approach. Find good candidates, do one phone interview and a second in-person interview in the space of a few days (not 4 or 5, stretched out over months). If they pass your initial 2 interviews, hire them as a 6 month contractor. See how much they accomplish in 6 months. If they are contributing and integrating effectively, hire them full time. If not, just wish them the best and don't renew their contract. This is the way it works in most effective large companies. The cream that rises to the top gets offered a full time job within a 6 month to 2 year timeframe. My current job is like that. I've worked there for 4 years and started as a contractor. It became so expensive to pay my hourly rate that they were begging me to become full time after a while. I was doing a valuable job for them and was very effective at it, so I got the full time offer.
LiveTheDream 16y ago
Not to mention that in a couple years you can become a much stronger hire anyway, especially early in your career going from 0 experience to 2 years. Experience = Time * Density [1] [1] http://stevehanov.ca/blog/index.php?id=105 http://stevehanov.ca/blog/index.php?id=105