4 ms·

I would never hire a product person from Google or someone I needed to be visionary. For the most part, their products suck, they have no vision and no follow

I would never hire a product person from Google or someone I needed to be visionary. For the most part, their products suck, they have no vision and no follow through. But their technology is top notch. I hire mostly for startups and green field initiatives though and I wouldn’t hire anyone from any BigTech company unless I had “hard” technical problems to solve. Yes I’ve done a stint at BigTech.

ninkendo 2y ago
They have top notch tech, yes, but it’s massively overkill for literally every company that’s not at google’s scale. If you’re not careful you may hire someone who will try to replicate everything google does, when you may need only 1% of the complexity. This is the experience I’ve generally had with xooglers… they lament that they don’t have the same tools/tech stack they had at google, and so their first act is to try to move everything to the closest open source equivalents, even if they’re not a good fit. There’s good things and bad things to take away from experience at google… you have to be careful to ignore things that won’t actually help you.
- scarface_74 2y ago
  I agree. I haven’t run into a “hard problem” in my career By hard problem I mean technically at the top 5% of a problems in the industry that can’t be solved by throwing money at a SaaS or using a cloud provider.
  - everfrustrated 2y ago
    Most companies are really just crud apps. Very few are doing anything technically innovative. And that's just fine. I wonder how much of the early Google technical innovation was more a product of open source tech/distributed systems being a lot more immature (I'm particularly thinking databases) 25 years ago. Ultimately all companies get bloated and loose their way. It shouldn't be a suprise this has happened to Google - 25 years on they are mega corp and idling. Probably for the best as it allows innovators a chance to compete.
- deepsun 2y ago
  I've been the "you're not google" person for several years, but now softened my position. The thing is -- it depends. Sometimes when everyone knows some complex system well -- it becomes easy. One example comes to mind -- Kubernetes. 90% of teams don't need all its complexity. And I've been "you don't need it" person for some time. But now I see that when everyone knows it -- it's actually much easier to deploy even simple websites on it, because it's a common lingo and you don't spend time explaining how it's deployed. It's not like civic engineers, when an over-engineered bridge would cost a lot more in materials.
  - scarface_74 2y ago
    If you have a simple website , you can containerize your backend and use much simpler services from AWS and serve your static assets on S3. Kubernetes is rarely the right answer for simple things even if Docker is.
    - mschuster91 2y ago
      > much simpler services from AWS Like what, Lambda? I've seen so much horrible hacks and shit done with it (and other AWS services cough API gateway cough), these days I rather prefer a set of Kubernetes descriptors and Dockerfiles. At least that combination all but enforces people doing Infrastructure-as-a-code and there's (almost) no possibility at all for "had to do live hack XYZ in the console and forgot to document it or apply it back in Terraform" .
      - scarface_74 2y ago
        AWS App Runner https://aws.amazon.com/blogs/containers/introducing-aws-app-runner/ https://aws.amazon.com/blogs/containers/introducing-aws-app-... Google has something similar.
        icedchai 2y ago
        GCP has Cloud Run, which looks similar. App Runner is basically a wrapper on top of Fargate, right?
- VirusNewbie 2y ago
  > but it’s massively overkill for literally every company that’s not at google’s scale. Before I worked at Google I was at a small telecom company that was running into limits of what some of the Dataflow/Apache Beam product could do, so we had to rewrite it (and commit it back to Beam). There are companies that have massive scaling issues even if they're not planet scale cloud providers or something. You can replicate a lot of Google tech now by....just using the OSS they release and/or jumping on a modern cloud provider (GCP or AWS). It's not 2012. You can use a good database and not have to reinvent it.
jarsin 2y ago
And now we are all stuck doing leetcode interviews primarily because of Google.
- marssaxman 2y ago
  Leetcode didn't exist back then; the site was founded a little less than a decade ago.
  - jarsin 2y ago
    I was using "Leetcode" as in style of the interview. The Leetcode website was founded due to everyone in the industry copying google/big tech in these style of interviews.
    - mike_hearn 2y ago
      Google copied that idea from Microsoft, primarily.
fweimer 2y ago
The flip side from this assumption about their technology is that if some service is not working, people are very quick to blame the impacted (paying) user. “You are running into rate limits”, “Google is applying anti-abuse controls to your account”, and so on. But at least for some services, I strongly suspect we are actually experiencing random system failures. In my experience, it's rare to get acknowledgement of this from Google. Tickets may not even make it to them because of this pervasive “Google technology is perfect” assumption. The end result feels a bit like gaslighting (doubting our sanity because we can't spot the pattern that is supposed to be obvious): we are encouraged to attribute meaning to more or less random reactions from a complex system.

ninkendo 2y ago

They have top notch tech, yes, but it’s massively overkill for literally every company that’s not at google’s scale. If you’re not careful you may hire someone who will try to replicate everything google does, when you may need only 1% of the complexity. This is the experience I’ve generally had with xooglers… they lament that they don’t have the same tools/tech stack they had at google, and so their first act is to try to move everything to the closest open source equivalents, even if they’re not a good fit. There’s good things and bad things to take away from experience at google… you have to be careful to ignore things that won’t actually help you.

scarface_74 2y ago
I agree. I haven’t run into a “hard problem” in my career By hard problem I mean technically at the top 5% of a problems in the industry that can’t be solved by throwing money at a SaaS or using a cloud provider.
- everfrustrated 2y ago
  Most companies are really just crud apps. Very few are doing anything technically innovative. And that's just fine. I wonder how much of the early Google technical innovation was more a product of open source tech/distributed systems being a lot more immature (I'm particularly thinking databases) 25 years ago. Ultimately all companies get bloated and loose their way. It shouldn't be a suprise this has happened to Google - 25 years on they are mega corp and idling. Probably for the best as it allows innovators a chance to compete.
deepsun 2y ago
I've been the "you're not google" person for several years, but now softened my position. The thing is -- it depends. Sometimes when everyone knows some complex system well -- it becomes easy. One example comes to mind -- Kubernetes. 90% of teams don't need all its complexity. And I've been "you don't need it" person for some time. But now I see that when everyone knows it -- it's actually much easier to deploy even simple websites on it, because it's a common lingo and you don't spend time explaining how it's deployed. It's not like civic engineers, when an over-engineered bridge would cost a lot more in materials.
- scarface_74 2y ago
  If you have a simple website , you can containerize your backend and use much simpler services from AWS and serve your static assets on S3. Kubernetes is rarely the right answer for simple things even if Docker is.
  - mschuster91 2y ago
    > much simpler services from AWS Like what, Lambda? I've seen so much horrible hacks and shit done with it (and other AWS services cough API gateway cough), these days I rather prefer a set of Kubernetes descriptors and Dockerfiles. At least that combination all but enforces people doing Infrastructure-as-a-code and there's (almost) no possibility at all for "had to do live hack XYZ in the console and forgot to document it or apply it back in Terraform" .
    - scarface_74 2y ago
      AWS App Runner https://aws.amazon.com/blogs/containers/introducing-aws-app-runner/ https://aws.amazon.com/blogs/containers/introducing-aws-app-... Google has something similar.
      - icedchai 2y ago
        GCP has Cloud Run, which looks similar. App Runner is basically a wrapper on top of Fargate, right?
VirusNewbie 2y ago
> but it’s massively overkill for literally every company that’s not at google’s scale. Before I worked at Google I was at a small telecom company that was running into limits of what some of the Dataflow/Apache Beam product could do, so we had to rewrite it (and commit it back to Beam). There are companies that have massive scaling issues even if they're not planet scale cloud providers or something. You can replicate a lot of Google tech now by....just using the OSS they release and/or jumping on a modern cloud provider (GCP or AWS). It's not 2012. You can use a good database and not have to reinvent it.

jarsin 2y ago

And now we are all stuck doing leetcode interviews primarily because of Google.

marssaxman 2y ago
Leetcode didn't exist back then; the site was founded a little less than a decade ago.
- jarsin 2y ago
  I was using "Leetcode" as in style of the interview. The Leetcode website was founded due to everyone in the industry copying google/big tech in these style of interviews.
  - mike_hearn 2y ago
    Google copied that idea from Microsoft, primarily.

fweimer 2y ago

The flip side from this assumption about their technology is that if some service is not working, people are very quick to blame the impacted (paying) user. “You are running into rate limits”, “Google is applying anti-abuse controls to your account”, and so on. But at least for some services, I strongly suspect we are actually experiencing random system failures. In my experience, it's rare to get acknowledgement of this from Google. Tickets may not even make it to them because of this pervasive “Google technology is perfect” assumption. The end result feels a bit like gaslighting (doubting our sanity because we can't spot the pattern that is supposed to be obvious): we are encouraged to attribute meaning to more or less random reactions from a complex system.