7 ms·

I'm sure they're asking about this in interviews now. My experience with Google interviews was that the interviewers were very keen on proving that they knew mo

I'm sure they're asking about this in interviews now. My experience with Google interviews was that the interviewers were very keen on proving that they knew more theoretical CS than I did vs talking about what the actual work would require or entail.

gefh 11y ago
You may well be asked how a distributed sort would work in principle, and be asked to code a small part of it. Any reasonable answer that shows you can think on your feet would be evidence in favor of hiring. It sounds like you didn't get hired, and I'm sorry about that. Interviewers' preferences are of course diverse, but for at least the last 5 years, probably 10, Google interviews favor practical solutions to problems we face every day. Some of those are theoretical CS, many are not.
- alexnewman 11y ago
  Lol normal Google arrogance. Yea they only seem to ask theoretical questions basically out of that famous book
  - alexnewman 11y ago
    Why did i get -4 vote here....
  - late2part 11y ago
    Maybe, maybe not. Most people's surface area of problems don't even approach Google's problems. The kind of things most companies aspire to solve, Google automated a decade ago. So, this esoteric CS theory may be more practical inside Google than your external vantage point can consider.
    - cmrdporcupine 11y ago
      The problems being automated years ago means the vast majority of Google engineers don't ever get close to having to work on those solutions. One of things that disappointed me after joining G was that many of the problems I found fun to solve at previous employers were a) solved already and b) solved by people much smarter and senior than me. It's a great place to work for all sorts of reasons. But working on cutting edge stuff, well, that requires that you be good at fighting on both meritocratic and political fronts. The majority of the people that came in the same acquisition as me left before their golden handcuff payouts finished, because of this.
      - fritzo 11y ago
        "with more rules we have solved most of the problems in the world. That just leaves the weird events" -Steve Coast The remaining problems are indeed weird, and succumb only after application of every available tool: "asking around", CS theory, low-level debugging, visualization, heavy logs analysis, pouring over source code, strolling aimlessly, mining commit history, politicking, brainstorming...
  - GauntletWizard 11y ago
    I think it more likely you have a bad grasp on what is and isn't theoretical for Google.
- existencebox 11y ago
  As a datapoint, a while back I was asked (for a G interview within the last 10 years) to code an RB tree from start to finish. I'll admit I was a little miffed at how distanced this seemed from anything I would potentially do; I was not interviewing for a high theory/deep algorithms group. That being said, in my other experience with a G interview, the entire process was much more mundane and as expected. For the record, I have both been hired and not hired by G and not necessarily paired with the above interviews as you'd expect. I mention this instance largely because my friends at the big G tell me such a question is generally frowned upon, and not part of standard practice, (So I don't feel bad speaking openly about it) but more importantly it gives me a way to see how people can get a skewed perspective on a company given a... unique interview question when the overall guidance within the corp wouldn't align to asking that.
  - asuffield 11y ago
    (Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.) "Within the last 10 years" covers several generations of refinement to the interview process. I'd suggest forgetting about anything more than a couple of years old. The major thing to keep in mind is that these days, your recruiter will ask you up front what subject areas you are strongest in, and you should expect to get interviews about those things.
    - drx 11y ago
      What's the process like these days?
      - mayanksinghal 11y ago
        Faster (at least it's attempting to be) without losing any quality metrics.
  - eru 11y ago
    > I was not interviewing for a high theory/deep algorithms [...] Implementing a well known data structure is pretty far removed from `deep algorithms' and `high theory'.
KMag 11y ago
I worked at Google, and performed quite a few interviews. At least at that time, the interviewer had no idea where in the company the software engineer would go. The people who got hired would go into a pool, and the managers who needed staff would then horse-trade for them. They needed to hire people who could be plugged in to tons of different positions, including some that genuinely had tough problems where if they accidentally did something in O(N^2), their half-day compute job would suddenly literally take centuries to complete. Also, part of the point of a Google style interview is to keep pushing you to the point where your ability fails, then push in another direction to the point your ability fails. That way, they get an idea of the dimensions of your skillset. The vast majority of the people I recommended hiring didn't answer the questions perfectly. Or, someone could not quite put enough thought into the integer encoding for Protocol Buffers. The encoding actually used is that the first bit of every byte is a flag for if there's a next byte, for a maximum of 10 bytes. The only advantage to this over encoding the length of the integer as the number of leading ones in the first byte (like UTF-8) is if they want the option to have the option later of a forward-compatible encoding for longer integer types, without just supporting multi-precision integers as byte arrays. If you slide all of those flag bits to the first byte, you don't have any more or any fewer flag bits, so it takes as much space, but you can use a jump table and the ability to use native 8-byte and 4-byte simple loads instead of many more masking operations and conditional branches. Giving up on anything longer than int64_t means that the maximum encoding length becomes 9 bytes instead of 10. One day, the speed of the indexing system just dropped in half. It turns out that someone wrote a job that used machine learning to generate a bunch of regexes for some signal. They were recompiling the regexes for every page in the index. Google really needs most of their engineers that will naturally spot this kind of thing in code reviews, because if every engineer on the indexing team made a mistake like that once a year, the indexing system would always run at half speed, sometimes even 1/3 or 1/4 speed. The indexing system uses as much electricity as a small town. The tiniest of improvements can mean thousands of dollars per year in savings.
- theoh 11y ago
  "an idea of the dimensions of your skillset" sounds like a really reductive way of thinking. It's as if the skillset is restricted to something easy to quickly explore and visualize, like a convex object in a few dimensions. Maybe those assumptions are necessary for interviewing but they're nothing to be proud of.
asdfologist 11y ago
The type of CS interview questions they ask aren't any different from what to expect at Facebook, Twitter, or any other tech firm in the valley. Many of my friends who are nowhere near the best CS students at my school passed their interviews without any problems. Is it perhaps remotely conceivable that you simply weren't well-prepared?

gefh 11y ago

You may well be asked how a distributed sort would work in principle, and be asked to code a small part of it. Any reasonable answer that shows you can think on your feet would be evidence in favor of hiring. It sounds like you didn't get hired, and I'm sorry about that. Interviewers' preferences are of course diverse, but for at least the last 5 years, probably 10, Google interviews favor practical solutions to problems we face every day. Some of those are theoretical CS, many are not.

alexnewman 11y ago
Lol normal Google arrogance. Yea they only seem to ask theoretical questions basically out of that famous book
- alexnewman 11y ago
  Why did i get -4 vote here....
- late2part 11y ago
  Maybe, maybe not. Most people's surface area of problems don't even approach Google's problems. The kind of things most companies aspire to solve, Google automated a decade ago. So, this esoteric CS theory may be more practical inside Google than your external vantage point can consider.
  - cmrdporcupine 11y ago
    The problems being automated years ago means the vast majority of Google engineers don't ever get close to having to work on those solutions. One of things that disappointed me after joining G was that many of the problems I found fun to solve at previous employers were a) solved already and b) solved by people much smarter and senior than me. It's a great place to work for all sorts of reasons. But working on cutting edge stuff, well, that requires that you be good at fighting on both meritocratic and political fronts. The majority of the people that came in the same acquisition as me left before their golden handcuff payouts finished, because of this.
    - fritzo 11y ago
      "with more rules we have solved most of the problems in the world. That just leaves the weird events" -Steve Coast The remaining problems are indeed weird, and succumb only after application of every available tool: "asking around", CS theory, low-level debugging, visualization, heavy logs analysis, pouring over source code, strolling aimlessly, mining commit history, politicking, brainstorming...
- GauntletWizard 11y ago
  I think it more likely you have a bad grasp on what is and isn't theoretical for Google.
existencebox 11y ago
As a datapoint, a while back I was asked (for a G interview within the last 10 years) to code an RB tree from start to finish. I'll admit I was a little miffed at how distanced this seemed from anything I would potentially do; I was not interviewing for a high theory/deep algorithms group. That being said, in my other experience with a G interview, the entire process was much more mundane and as expected. For the record, I have both been hired and not hired by G and not necessarily paired with the above interviews as you'd expect. I mention this instance largely because my friends at the big G tell me such a question is generally frowned upon, and not part of standard practice, (So I don't feel bad speaking openly about it) but more importantly it gives me a way to see how people can get a skewed perspective on a company given a... unique interview question when the overall guidance within the corp wouldn't align to asking that.
- asuffield 11y ago
  (Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.) "Within the last 10 years" covers several generations of refinement to the interview process. I'd suggest forgetting about anything more than a couple of years old. The major thing to keep in mind is that these days, your recruiter will ask you up front what subject areas you are strongest in, and you should expect to get interviews about those things.
  - drx 11y ago
    What's the process like these days?
    - mayanksinghal 11y ago
      Faster (at least it's attempting to be) without losing any quality metrics.
- eru 11y ago
  > I was not interviewing for a high theory/deep algorithms [...] Implementing a well known data structure is pretty far removed from `deep algorithms' and `high theory'.

KMag 11y ago

I worked at Google, and performed quite a few interviews. At least at that time, the interviewer had no idea where in the company the software engineer would go. The people who got hired would go into a pool, and the managers who needed staff would then horse-trade for them. They needed to hire people who could be plugged in to tons of different positions, including some that genuinely had tough problems where if they accidentally did something in O(N^2), their half-day compute job would suddenly literally take centuries to complete. Also, part of the point of a Google style interview is to keep pushing you to the point where your ability fails, then push in another direction to the point your ability fails. That way, they get an idea of the dimensions of your skillset. The vast majority of the people I recommended hiring didn't answer the questions perfectly. Or, someone could not quite put enough thought into the integer encoding for Protocol Buffers. The encoding actually used is that the first bit of every byte is a flag for if there's a next byte, for a maximum of 10 bytes. The only advantage to this over encoding the length of the integer as the number of leading ones in the first byte (like UTF-8) is if they want the option to have the option later of a forward-compatible encoding for longer integer types, without just supporting multi-precision integers as byte arrays. If you slide all of those flag bits to the first byte, you don't have any more or any fewer flag bits, so it takes as much space, but you can use a jump table and the ability to use native 8-byte and 4-byte simple loads instead of many more masking operations and conditional branches. Giving up on anything longer than int64_t means that the maximum encoding length becomes 9 bytes instead of 10. One day, the speed of the indexing system just dropped in half. It turns out that someone wrote a job that used machine learning to generate a bunch of regexes for some signal. They were recompiling the regexes for every page in the index. Google really needs most of their engineers that will naturally spot this kind of thing in code reviews, because if every engineer on the indexing team made a mistake like that once a year, the indexing system would always run at half speed, sometimes even 1/3 or 1/4 speed. The indexing system uses as much electricity as a small town. The tiniest of improvements can mean thousands of dollars per year in savings.

theoh 11y ago
"an idea of the dimensions of your skillset" sounds like a really reductive way of thinking. It's as if the skillset is restricted to something easy to quickly explore and visualize, like a convex object in a few dimensions. Maybe those assumptions are necessary for interviewing but they're nothing to be proud of.

asdfologist 11y ago

The type of CS interview questions they ask aren't any different from what to expect at Facebook, Twitter, or any other tech firm in the valley. Many of my friends who are nowhere near the best CS students at my school passed their interviews without any problems. Is it perhaps remotely conceivable that you simply weren't well-prepared?