Live data from Hacker News

Sunsetting Hire

support.google.com

281–290 of 301 posts

Re: Sunsetting Hire

#281
post #163

What is humorous to me is that Google is hurting users who typically have the most influence over SaaS integrations at their company (managers) by taking away a tool that helped them deal with the part of their job most of them hate the most (hiring/recruiting). If it hasn't been obvious yet to managers watching this, Google's software is not a safe investment for you to make for your company. It is only a matter of…

Whether it's actually safe or not, there's a plausible narrative that it is not and won't be. When I'm doing tech selection, things like this will keep me from picking Google every time.

Especially if I'm working for a large business.

One of the reasons big companies move slower is maturity. You are expected to keep doing something once you put it out there. Otherwise you're seen as a risky partner and avoided.

The only other way to go is to make the things you support so simple that people could, if pressed, do their own maintenance if you pull a fade. Abandonware with a prayer of being adopted by internal people.

Re: Sunsetting Hire

#282
post #280

Earlier quoted context omitted.

Note: I work on App Engine. Go 1.11 supports all legacy 1st generation APIs. It's in the first section of the doc [2] that you posted although perhaps we can make this even clearer. We maintained support for these APIs precisely to make this migration extremely straightforward for our existing users as we moved to a more modern underlying technology stack and a version of Go supported by the language community. We ab…

Was this done proactively or reactively after many months of negative feedback? If it was the former that gives me a lot more faith in app engine after trialing in some years ago and giving up on it.

Proactively. It was in the initial email about the Go 1.9 turndown sent to users. We definitely understand that any code change is painful, no matter how trivial. Supporting legacy APIs on a modern Go runtime seemed like the right balance between keeping up with the language community while bringing along our existing users.

Re: Sunsetting Hire

#283
post #254
post #194

Earlier quoted context omitted.

Bebop was an acqui-hire, not a real product. All they wanted was the CEO. I don't think anyone took the product seriously except for the person who started it, and once she left Google, there was no reason to continue pretending that it was a real thing.

The trouble is that if you have to understand or correctly guess internal Google politics like this in order to know which products you can really rely on, then it's effectively not reliable. With that said, I'd feel fine relying on VMs, disks, managed SQL, managed Kubernetes, etc. Maybe I'm too optimistic. And Google is giving exactly the guarantees they promised - 1 year of notice before shutting down a product.

And if Google finally figures out that they're slowly re-implementing half of Erlang, badly, then half of this could evaporate within a couple years.

(Given their history I'd expect it's more likely they build their own BEAM and put a new language on top of it)

Re: Sunsetting Hire

#284
post #247

Earlier quoted context omitted.

I agree that not becoming dependent on nascent Google projects is a good call for for consumers. But their cloud offering seems to be pretty stable and reliable. It feels almost as if their consumer and cloud arms are different companies.

I certainly hope this is true but I hold a healthy degree of skeptism when using one of their cloud products. This is unfortunate, because overall I've found GCP to be quite far ahead of AWS in terms of product design and integrations.

can you elaborate more about 'GCP to be quite far ahead of AWS in terms of product design and integrations'?

Re: Sunsetting Hire

#285
post #75
post #53

Starting to think that the key is to build your toys on a VM you control. That way nobody can take them away Proprietary stuff is starting to become flakey not in the uptime sense but pure lifespan. Almost like planned obsolescence became a thing with gear

I'd love this, a private server that ran apps (running on my box at home or maybe on an AWS instance) I can access via a web browser: no more senseless version upgrades with all the UI changes to boot, dropped file formats, license key nightmares, and of course ended products.

Do it!

It comes with it's own set of challenges, but I've found with the advent of docker it's quit easy to test running your own xyz server.

Re: Sunsetting Hire

#286
post #53

Starting to think that the key is to build your toys on a VM you control. That way nobody can take them away Proprietary stuff is starting to become flakey not in the uptime sense but pure lifespan. Almost like planned obsolescence became a thing with gear

Some people have never stopped thinking that way. Some of us have questioned every single "we'll just use google " decision/discussion every time it's come up.

Yep. Though some of the cloud glue-like things sure do seem appealing.

So my current thinking is build it on VM but glue it together with cloud...ideally with something that is available in multiple clouds. e.g. GCP and Azure both have pub/sub and both have cloud functions

Re: Sunsetting Hire

#287

Earlier quoted context omitted.

When I get involved with a random 10 person company, I know what I'm getting into. Using the google brand provides(provided) a sense of respectability and deeper pockets/longer term vision. Some users, I believe rightfully so, feel betrayed by google's lackadaisical approach to starting and shutting down projects. Especially when comparing the effort to market vs create a great product. Like google +, it was shoved d…

Google internally is like a mini VC ecosystem. Google leaders calculate the opportunity cost of headcount instead of the actual cost, so if a project isn't worth at least a million per man-year it gets shut down in favor of other projects which might fuel the system in the future.

Yes, but when a VC creates a product, he doesn't name it:

VC's Product Name

Why? Because then his name is behind it. Instead, he invests.

Google could choose to create products that aren't google branded as an experiment. Then they can win/fail on their own merit.

But google doesn't choose to do that. They use their branding and marketing machine. They know they are using their brand to create trust. Then they betray it.

Seems pretty clear to me and it even seems odd the naivete some people here display, it's almost as if they had an interest in seeing google as a force of good, when they clearly removed their 'do no evil'.

There is a choice being made, and the choice has a reason. They have every right to do as they please with their brand, we have every right to find it sneaky, dishonest and something that makes us less likely to get burned again (jumping on board other google projects)

For better or worse, brands exist. I love my Nike shoes because they are super comfortable and last a long time. I might be able to get cheaper sneakers that are just as good. But I'm loyal to the brand because they consistently produce great products. If that stopped being the case, I'd stop paying the Nike brand premium. Can Nike experiment? Sure, hopefully not under the Nike brand (in fact, that does happen, many companies in many industries own more than one brand and keep the flagship brand separate from more experimental brands on a PR basis)

Re: Sunsetting Hire

#288
post #51

Earlier quoted context omitted.

This all seems pretty fair to me. I know how to evaluate a startup's potential failure. Who's funding them? How much money do they have? How popular are they? How solid's the product? What are the founders like? Heck, for a lot of small startups, you can just ask to talk to the CEO if it's what it will take to close the deal. And I have a good idea of the conditions under which they'll throw in the towel. But Google…

> And it stopped existing because she left Google. How could I possibly predict that? It's pretty easy really, and you don't have to predict Google executive tenures: if the founder of a service you are considering using sells the company to Google and runs a completely different product division afterwards, even if that service doesn't immediately sunset and lives on as a vanity project, it will die of neglect. The…

Ah, so the solution is to understand the internal culture of every company you do business with?

Our definition of 'easy really' might be very different. In fact, whenever someone talks about complex topics and starts off with 'easy really' I cringe. There's a certain perspective people have to have to use such language, and that perspective is very far from my general understanding that 'reality is complex'.

Re: Sunsetting Hire

#289
I think Google, as most do, underestimated the time and effort it takes to build a recruiting suite, even for the SMB market. I've spent 5 years SmartRecruiters as PM and in partnerships. It's taken 80 engineers a good 5+ years to build a clean solution that can scale globally with different local customs, job boards, assessments, and regulations.

Re: Sunsetting Hire

#290
post #117

Founder and CEO of Agave.com here. We're a new player in the space and we've focused on making it easy for startups to get going quickly with an ATS that doesn't suck. If you're interested in a demo or getting an invite to join (we haven't launched publicly yet), shoot me an email at jared@agave.com.

Do you have an XML job feed?

We are aggregating jobs from ATS-es.

https://www.postjobfree.com/include-job-feed

Post reply on HN