This is so cool - thank you! I have a very (ahem) useful purpose for this: I use a command line application that calls back to a browser during authentication and that alone prevented me from doing what I needed/wanted from an ssh terminal... I will now happily laugh my ass off as it launches firefox from inside my terminal every time I use it.
Are they not worried about people seeing the joke requirement in the job spec, just not being aware of the current Twitter joke of the day, and discounting themselves?
No, it's selecting candidates who are aware of the current Twitter joke of the day. They're either unaware of how small that bubble is or accepting of the monoculture this promotes.
I'm sure people who are not aware will just search for it in their favorite search engine and find out it's a joke.
What it might filter out are people who don't find this joke funny, and might decide not to apply (and on the countrary it will catch the attention of people finding this funny and concluding Signal must be a cool place to work).
Getting devs attention on a job offer is hard these days, so I guess spicing it a bit is fair.
I, for one, wouldn't bother searching for a technology that I've never heard of if it were listed as a requirement for a job posting. I would just move on to the next posting.
There are too many jobs that I am qualified for to bother taking time for a deep dive on a job that I'm not qualified for.
To be honest I haven't ever actually looked for a job, but if I happened to read that annonce, I would absolutely check out wtf is that tech that is a requirement to work at signal, out of pure curiosity.
Also it probably depends whether you have actually used some aws services. I have searched quite a lot of aws services before, and not finding the product page straight away is a pretty good hint.
The thing is they change/deprecate/retire paid-for services too (in a brutal contrast with the competiton).
Two quotes from one of the posts referenced in the submission (from Steve Yegge):
...I know I haven’t gone into a lot of specific details about GCP’s deprecations. I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to… I dunno, everything, has forced me to rewrite it all after at most 2–3 years, and they never automate it for you, and often there is no documented migration path at all. It’s just crickets. And every time, I look over at AWS, and I ask myself what the fuck I’m still doing on GCP. ...
... Update 3, Aug 31 2020: A Google engineer in Cloud Marketplace who happens to be an old friend of mine contacted me to find out why C2D didn’t work, and we eventually figured out that it was because I had committed the sin of creating my network a few years ago, and C2D was failing for legacy networks due to a missing subnet parameter in their templates. I guess my advice to prospective GCP users is to make sure you know a lot of people at Google… ...
On the first, I've worked as a PM on Firebase, App Engine, and Endpoints.
Nobody has been forced to migrate from the Firebase RTDB to Firestore (and AFAICT the Firestore API hasn't deprecated anything?), App Engine deprecations (https://cloud.google.com/appengine/docs/deprecations) are basically "you can't do new things using these old things, but the old ones will continue to run" (though other deprecations I've done have provided clear explanations of why we're deprecating and how someone can work around it), and Endpoints is still around despite being comically out of date (it's even getting a managed version!).
About deprecation: the gold standard is what AWS is doing with SimpleDB: essentially, never.
The thing here is that if you run hundreds of services in production - many of which work smoothly and you don't need to touch often, you will find that Google's habit of forcing you to change how to use their tooling will generate a huge burden...
They discourage you from using it and make it clear that for every use case some other tool at AWS would be best, and have been doing so for several years now... They wont even list it anymore under https://aws.amazon.com/products/databases/ ..
Still, they support it ( https://aws.amazon.com/simpledb/ ) because there are customers with legacy systems that depend upon this service.
I thought the new title better but I did not want to change the original (because I had already shared the link with friends), so I just changed when submitting. Should've gone with the original...
